Print Page - SIGS/WON

Projects & Development => Outpost 2 Programming & Development => Topic started by: Hooman on December 05, 2006, 09:09:50 PM

Title: SIGS/WON
Post by: Hooman on December 05, 2006, 09:09:50 PM

For those interested in a bit on how SIGS worked, here's what I've found out. This info was extracted from a CD install of OP2 with the 3 official updated applied.

It uses TCP connections for all communications. It breaks and remakes connections depending on what it's doing, and can have more than one active connection.

A total of 118 messages are used. Each message has from 0 to 23 data fields, with a total of 342 data fields across all messages. The number of data fields of each type breaks down as follows:
int (big endian) : 131
float : 1
short (big endian) : 10
char : 28
string (null terminated) : 164
buffer (4 byte length prefixed) : 8

The exact data format (in terms of what type of data fields are used, and the order they are in) is known for each packet type. Although, there are a few packets where the client tries to unpack fields that apparently don't exist.

Despite the above, the meaning of each field is still unknown for the majority of the data fields. So although we know a certain packet has an int followed by a string in it, it is still unknown what the packet as a whole means, what the int means, and what the string data type is supposed to hold.

The client is extremely sensitive to correct data being returned. If incorrect data is returned, or an expected packet is not received, the client will most likely either hang or crash.

A simple test server has been written with hardcoded responses to each received packet from the client in an attempt to discover more about how the protocol works. This simple test server is nowhere close to what needs to be written for a real server though. To change what it returns requires a recompile. Further, it takes two instances of the test server running to handle one connecting client (and doesn't share data between the two instances). The only purpose to this server is to see how the client reacts to different messages in an attempt to figure out how the protocol works.

The simple test server can fool the client into getting through basic login and an initial room join. Images of the various clients states can be found here (http://www.hooman.outpostuniverse.net/images/SIGS/).

After version checking and login, the client goes into a receive loop for the lobby server. From there, it can process 22 message types. Of these messages, about 15 are fairly well understood.

When a room is joined, the client goes into a receive loop for the room server. From here it can process 23 message types. Of these messages, about 11 are fairly well understood.

Although some of the packets for creating and joining games are known, the data fields for these packets are largely unknown and no successful game create or game join has been accomplished at this point.

There are 7 known message receive loops, not including the version check/update and login process. Of these 1 is not used, but simply serves as a really basic model for the others to follow (think inheritance), leaving 6 message receive loops to consider. It appears 3 of them are for the lobby server, room server, and game server. The remaining receive loops only handle 2 or 3 messages. There seems to be code for opening UDP sockets in the client, but it is not known how to use UDP, or if this is even active code.

The SIGS DLLs appear to have been written with an MS C++ compiler with exception handling turned on. There is a lot of copying data around along with constructor and destructor calls. This combined with the exception handling code makes for much harder code to read. It's also frustrating to see a string get copied 3 times before it's actually used (or sometimes ignored), largely through a series of automatic constructor calls that were probably inserted by the compiler. There is also heavy use of classes and inheritance, Windows API calls, callback functions, and window message handling. Suffice it to say it's not the easiest code to read through.

Edit: Updated UDP assumptions.

Title: SIGS/WON
Post by: Leviathan on December 05, 2006, 09:13:21 PM

Interesting and great work :)

Looks a lot different from the updated WON version of SIGS I used to play on.

Title: SIGS/WON
Post by: Hooman on December 05, 2006, 09:17:30 PM

I took a look at the updated WON DLLs once a long time back. They seem to use the same message formats as the SIGS DLLs do, but I think they may have extended the protocol a little.

Btw, this project hasn't received much attention lately. Most of the work is probably from a year ago (maybe two). I took it up again recently and made some more progress, but it's again been put aside due to lack of time.

Title: SIGS/WON
Post by: Leviathan on December 05, 2006, 09:44:02 PM

Yeah I know you were working on it ages ago and you posted your findings.

What is the test server written in? Can it be written in any language out of interest as long as it talks to the client correctly?

Title: SIGS/WON
Post by: Hooman on December 05, 2006, 10:08:38 PM

The language doesn't matter. I used MSVC to compile the server, though it was only C code. The use of null terminated strings suggests they'd planned to use C/C++ for this. They're the most natural to handle in C/C++. Plus, there are certain things that are easier to handle in a language that allows an unspecified number of parameters to a function like printf uses.

Title: SIGS/WON
Post by: Hooman on March 16, 2007, 01:58:53 AM

Time to post some more data on this. Some of it is a little old and stale, but this might be a good excuse to get some of it cleaned up. Plus I'm starting to get the feeling that I didn't write down a few things that were once obvious, but not so much anymore. These are largely taken from text files that I've built up while analysing the code.

Quote

SIGS
----

There are two parts to establishing a SIGS connection. The first part involves
connecting to the update server to check for updates. The server is checked for
updates to both the SIGS system DLLs as well as updates to the game being played.
Once this step is completed, the connection is broken. A game server address is
negotiated during the update process which is later used to establish a connection
to login as a specific player.

Quote

Data Packets
------------

The following describes the TCP stream, how it is broken up into packets, and
how the packets are structured.

Each packet has a DWORD length prefix in Big Endian byte ordering. The value
(after endian conversion for an Intel processor) gives the length of the
following data (not including this length prefix). This data is collected into
a buffer, and then processed and broken into it's component parts. The data
after the length prefix will be collectively denoted as the "message" hereafter.

All messages have a header of 3 fields, all stored in Big Endian byte ordering
(and need to be adjusted on Intel processors). Following these 3 fields are
the message specific data, which varies from message type to message type.
Note that the first field of the message data is also a length prefix. This
value appears to be redundant as it is the same as the length prefix before the
message data. (This message length includes the size of itself along with the
size of the rest of the message).

Thus, the format of packets is as follows:

Offset   Message Offset Size   Description
------ -------------- ----   -----------
0x0   -X- 4 Length prefix of following data   (Big Endian)
- - - - - - - - - - - - - - - - - - - - - -
0x4   0x0 4 MessageLength   (Big Endian)
0x8   0x4 4 MessageType   (Big Endian)
0xC   0x8 4 Flags? (MSB is either 1 or 9)   (Big Endian)
- - - - - - - - - - - - - - - - - - - - - -
0x10   0xC Variable   Message specific data. (*Some* data will be Big Endian)
...

Note: The "Flags?" value use is unknown, but values in the most significant byte
other than 1 or 9 cause the message to be discarded. The lower order bytes are
not checked in the comparison. Also, all values passed by the client seem to use
the value 1.

Quote

Part 1: Check For Updates
-------------------------

Note: Part 1 of the connection is handled by SNWValid.dll.
The client attempts to contact the SIGS server using TCP on port 7800.
A typical exchange where no updates are available is as follows:

Message # Data Direction   Description
--------- --------------   -----------
0 Client to Server   (0x268) 616. SIGS DLL version check
1 Server to Client   (0x385) 901. Connection successful
2 Client to Server   (0x272) 626. Game version check
3 Server to Client   (0x38B? 907?. - doesn't matter? First data element >= 0, or not 0x38B?)
Connection terminated

Message Values
--------------

The following list are the message types found to be in use by the client (or
explicitly checked for by the client). All messages from the client to the
server are in the 600 range, and all messages from the server to the client
are in the 900 range.

Client -> SIGS Server
---------------------
0x268 616   Request SIGS version check
0x269 617   Request SIGS update
0x272 626   Request game version check

SIGS Server -> Client
---------------------
0x385 901   Connection successful? (OK? Probably just a simple OK/Success message)
0x386 902   Game requested was not found on the server
0x387 903   SIGS DLL requires updated
0x388 904   (Sending SIGS update?)
0x38A 906   (SIGS update file packet?)
0x38B 907   Game requires update

Quote

Part 2
------

A TCP connection is established to the address and port designated in the (0x385) 901 Connection
successful packet. The packet format is the same as that used in Part 1.

Particularly interesting messages seem to be:
(0x259) 601 Login
(0x25B) 603 RequestRoomCreate

Useful Messages
---------------
Only certain mesages from the server are processed by the client. (After a connection is established)

0x001 001 MessagePack

0x065 101 RoomServerConnectStatus
0x06A 106 PlayerDisconnect?
0x06D 109 ChangeGamingProfile

0x0CF 207 RoomServerPing

0x12E 302 (Reads packet field and discards result. Technically this is an ignore.)
0x12F 303 RoomJoinStatus
0x130 304 (RoomCreation status response)
0x131 305 (Reads packet field and discards result. Technically this is an ignore.)
0x132 306 AddRoom
0x133 307
0x134 308 PlayerFoundInRoom
0x135 309 RemoveRoom?/Player?
0x136 310 UpdateRoomPop
0x138 312
0x139 313 ChangeGamingProfileStatus
0x13A 314
0x13B 315 ChangeMembershipProfileStatus
0x13C 316

0x192 402
0x193 403
0x19B 411

0x321 801 SysOp message (Probably for system broadcast usage)
0x322 802 Private from SysOP
0x323 803 News and Info

Ignored Messages
----------------
These messages are explicitly checked for, but are still ignored.
(Only those listed in the range 0x3XX. All messages check for in the 0x2XX range are ignored.)

0x324 804
0x385 901
0x386 902
0x387 903
0x388 904
0x389 905
0x38A 906
0x38B 907

Note that the messageTypes are blocked in groups of 100 (Starting at X01). The messages in each block appear to be highly related. They often appear to be sent mainly in one direction. There are 9 main blocks of message types. The first is simply for packing a number of messages into one packet (but seems a little pointless for a TCP connection). The next set seems to be LobbyServer related, and mainly client to server (trying to join rooms, getting/updating the player's profile, logging out). There are also blocks for the update sequence, sysop/server/news messages, and game update replies.

I'll just post the complete list of messages and formats (with incomplete descriptions of all the fields of course). I should also mention that although the message formats should be completely correct (as they were to a large extent machine generated/extracted) there appears to be coding errors where they try to unpack fields that don't exist in certain packets. I tried to make notes of places where I found this to be the case. The packets seem to be largely ignored however (or at least the "extra" fields extracted).

Oh, and of course here's the meaning of the meta data that describes the data formats:

Quote

Message Data Fields
--------------------

Note: The variable message data consists of 9 basic data types. These 9 cases
are summarized below.

Case Data Size Type/Description
---- --------- ----------------
0   2 WORD (short)
1   4 DWORD (int, Big Endian)
2   4 float?
3   8 double?
4   2 WORD (short, Big Endian)
5   4 DWORD (int)
6   1 BYTE (char)
7   X (variable)   String - NULL terminated string
8   X (variable)   Buffer - length prefixed buffer (4 byte length prefix,
followed by corresponding amount of data)

Title: SIGS/WON
Post by: Hooman on March 16, 2007, 02:04:47 AM

Quote

Message Data Formats
--------------------

The following describes the variable portion of each message, listed in order
of MessageType. The message header will not be listed for brevity. This is the
data starting at MessageOffset 0xC. All fields are packed one after the other
with no alignment bytes.

Quote

Note: A marking of: (Unimplemented)
   means the client has only a dummy stub
   function that returns right away as the
   message handler
Note: A marking of: (Unfinished)
   means the client has slightly more
   than a dummy stub function that just
   returns right away. In this case the
   fields from the network message are
   first unpacked into local variables
   ... and then the function just returns
   without doing anything.
   For all intents and purposes, this is
   just as good as (Unimplemented) above,
   but a little less immediately recognizable
   when examining the assembly code.

-----------------------------------
***********************************
-----------------------------------

MessageType : 1 (0x1)
MessageName : MessagePack
Description : Allows multiple messages to be processed
in one network transaction.
NumDataFields : 1
---------------
Index   DataType   Description
-----   --------   -----------
0   8 (Buffer)   messageData - Packed buffer of messages

MessageType : 2 (0x2)
MessageName :
Description : (Unimplemented)
NumDataFields : 2
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)
1   8 (Buffer)

-----------------------------------
***********************************
-----------------------------------

MessageType : 101 (0x65)
MessageName : RoomServerConnectStatus
Description : Notifies the client if a connection to a room
server was successful or not.
(Displays a message on error, and ignored
otherwise).
NumDataFields : 2
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)   roomServerName
1   1 (Int) connectStatus (-1 == failure, otherwise success)

MessageType : 102 (0x66)
MessageName :
Description :
NumDataFields : 3
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)   (Unused)
1   7 (String)   (Unused)
2   1 (Int) (Unused)

MessageType : 103 (0x67)
MessageName :
Description : (Unimplemented)
NumDataFields : 4
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)
1   7 (String)
2   1 (Int)
3   1 (Int)

MessageType : 104 (0x68)
MessageName : Logout
Description : (Unimplemented)
NumDataFields : 1
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)   playerName

MessageType : 105 (0x69)
MessageName :
Description : (Unimplemented)
NumDataFields : 1
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)

MessageType : 106 (0x6a)
MessageName : PlayerDisconnectFromRoomServer
Description : Notifies the client that a game was launched
(Unsuccessfully?)
(Sleeps for 2000ms before processing)
NumDataFields : 1
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)   (ignored) (playerName?)

MessageType : 107 (0x6b)
MessageName : RoomServerPingResponse
Description : (Unimplemented)
(Client reponse to server message 207 (RoomServerPing))
NumDataFields : 0
---------------
Index   DataType   Description
-----   --------   -----------
(Intentionally left blank)

MessageType : 108 (0x6c)
MessageName :
Description : (Unimplemented)
NumDataFields : 3
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)
1   1 (Int)
2   1 (Int)

MessageType : 109 (0x6d)
MessageName : ChangeGamingProfile
Description : (Preferences->User Data->Change Gaming Profile...)
NumDataFields : 5
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)   playerName
1   7 (String)   playerName (Must match player name to update)
2   6 (Char)   skillLevel
1=Novice
2=Intermediate
3=Advanced
4=Guru
3   7 (String)   tagLine "What would you like others to know?"
4   7 (String)   location

MessageType : 110 (0x6e)
MessageName :
Description : (Unimplemented in LobbyServerConnection)
(Starts a new receive thread in RoomServerConnection)
(Something to do with UDP?)
NumDataFields : 2
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)
1   1 (Int)

MessageType : 111 (0x6f)
MessageName : ConnectToRoomServer
Description : (Unimplemented)
(Message from client to server)
NumDataFields : 7
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)   playerName
1   7 (String)   playerName
2   6 (Char)
3   7 (String)   tagLine
4   7 (String)   location
5   7 (String)   ipAddress (of who? client?)
6   1 (Int) gamePort (of client)

-----------------------------------
***********************************
-----------------------------------

MessageType : 201 (0xc9)
MessageName : AddPlayerToRoom (AddToPlayerChatList)
Description : Adds a player to the "Player Chat List"
(left of main SIGS screen)
The client uses this list to select who gets
private messages.
NumDataFields : 1
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)   playerName

MessageType : 202 (0xca)
MessageName : RemovePlayerFromRoom (RemoveFromPlayerChatList)
Description : Removes a user from the "Player Chat List"
(Left of main SIGS screen)
The client uses this list to select who gets
private messages.
NumDataFields : 1
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)   playerName

MessageType : 203 (0xcb)
MessageName :
Description :
NumDataFields : 1
---------------
Index   DataType   Description
-----   --------   -----------
0   1 (Int)

MessageType : 204 (0xcc)
MessageName :
Description :
NumDataFields : 1
---------------
Index   DataType   Description
-----   --------   -----------
0   1 (Int)

MessageType : 205 (0xcd)
MessageName :
Description :
NumDataFields : 3
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)
1   7 (String)
2   1 (Int)

MessageType : 206 (0xce)
MessageName :
Description :
NumDataFields : 1
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)

MessageType : 207 (0xcf)
MessageName : PingRoomServer
Description :
NumDataFields : 0
---------------
Index   DataType   Description
-----   --------   -----------
(Intentionally left blank)

MessageType : 208 (0xd0)
MessageName :
Description :
NumDataFields : 3
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)
1   7 (String)
2   1 (Int)

MessageType : 209 (0xd1)
MessageName :
Description :
NumDataFields : 21
---------------
Index   DataType   Description
-----   --------   -----------
0   1 (Int)
1   1 (Int)
2   7 (String)
3   7 (String)
4   7 (String)
5   7 (String)
6   1 (Int)
7   1 (Int)
8   1 (Int)
9   1 (Int)
10   1 (Int)
11   1 (Int)
12   1 (Int)
13   1 (Int)
14   1 (Int)
15   1 (Int)
16   1 (Int)
17   1 (Int)
18   1 (Int)
19   1 (Int)
20   1 (Int)

-----------------------------------
***********************************
-----------------------------------

MessageType : 301 (0x12d)
MessageName : BadDllRevisionDetected
Description : Can be sent to the user after they submit a new
member profile.
NumDataFields : 1
---------------
Index   DataType   Description
-----   --------   -----------
0   2 (Float)   requiredRevision

MessageType : 302 (0x12e)
MessageName :
Description : (Unfinished)
NumDataFields : 3
---------------
Index   DataType   Description
-----   --------   -----------
0   1 (Int)
1   7 (String)
2   7 (String)

MessageType : 303 (0x12f)
MessageName : RoomJoinStatus
Description : [*** Very Important Message! ***]
If roomJoinStatus != 0 then code executes
that prevents the client from crashing when
SIGS exits.
If roomJoinStatus == 0, and a function succeeds,
then a new thread is created to listen for
incomming packets [RoomServerReceiveThread]
NumDataFields : 1
---------------
Index   DataType   Description
-----   --------   -----------
0   1 (Int) roomJoinStatus (0 == ???, -2 == RoomFull, nonzero == ???)

MessageType : 304 (0x130)
MessageName : RoomCreationStatusResponse
Description :
NumDataFields : 1
---------------
Index   DataType   Description
-----   --------   -----------
0   1 (Int) roomCreationStatus (0 == success?, 0x78 == obscenity, other == communication error)

MessageType : 305 (0x131)
MessageName :
Description : (Unfinished)
NumDataFields : 1
---------------
Index   DataType   Description
-----   --------   -----------
0   1 (Int)

MessageType : 306 (0x132)
MessageName : AddRoom
Description : Informs the client of a room available to the
user to join.
NumDataFields : 11
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)   roomName
1   7 (String)   gameType (Ex: "Last One Standing")
2   1 (Int) roomID (0 == Reserved)
3   1 (Int) numPlayers (NumPlayer currently in this room)
4   1 (Int) (Unused, but passed to AddRoom)
5   1 (Int) (Unused)
6   6 (Char)   (Unused, but passed to AddRoom)
7   7 (String)   roomPassword (Verified by joining client)
8   7 (String)   roomDescription
9   7 (String)   roomNetworkAddress
10   1 (Int) roomPortNumber

MessageType : 307 (0x133)
MessageName :
Description :
NumDataFields : 3
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)
1   7 (String)
2   1 (Int)

MessageType : 308 (0x134)
MessageName : PlayerFoundInRoom
Description :
NumDataFields : 1
---------------
Index   DataType   Description
-----   --------   -----------
0   1 (Int) roomID (-1 == Not Found)

MessageType : 309 (0x135)
MessageName : RemoveRoom/Player?
Description :
NumDataFields : 1
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)   roomName?

MessageType : 310 (0x136)
MessageName : UpdateRoomPop
Description :
NumDataFields : 2
---------------
Index   DataType   Description
-----   --------   -----------
0   1 (Int) roomID
1   1 (Int) newNumPlayers

MessageType : 311 (0x137)
MessageName :
Description :
NumDataFields : 2
---------------
Index   DataType   Description
-----   --------   -----------
0   1 (Int)
1   7 (String)

MessageType : 312 (0x138)
MessageName :
Description : (if boolSetRoomName != 0 then [global] roomName
is initialized with another string [empty?])
NumDataFields : 2
---------------
Index   DataType   Description
-----   --------   -----------
0   1 (Int) boolSetRoomName
1   1 (Int) (Unused)

MessageType : 313 (0x139)
MessageName : ChangeGamingProfileStatus
Description :
NumDataFields : 1
---------------
Index   DataType   Description
-----   --------   -----------
0   1 (Int) changeGamingProfileStatus
0 == Fail silently?
1 == Success?
2 == Nickname already in use
0x78 == Obscenity

MessageType : 314 (0x13a)
MessageName : MemberProfile
Description : Message from SIGS server to the client containing
the membership profile to the user.
This can be used to set the profile to meaningful
values upon login. (Profile stored on the server).
NumDataFields : 20
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)   memberName
1   7 (String)   realName
2   7 (String)   password
3   7 (String)   address1
4   7 (String)   address2
5   7 (String)   city
6   7 (String)   state
7   7 (String)   country
8   7 (String)   postalCode
9   7 (String)   emailAddress
10   7 (String)   internetService ("Other")
11   4 (Short)   boolCD_ROM (0 == No CD, 1 == CD)
12   4 (Short)   boolMicrophone (0 == No Mic, 1 == Mic)
13   1 (Int)
14   6 (Char)   age
1 == "< 7"
2 == "7 - 12"
3 == "13 - 18"
4 == "19 - 25"
5 == "26 - 40"
6 == "41 - 54"
7 == "55+"
99 == "My Secret"
15   6 (Char)   gender
1 == "Male"
2 == "Female"
9 == "My Secret"
16   6 (Char)   connectionSpeed
1 == "2400"
2 == "9600"
3 == "14,400"
4 == "28,800"
5 == "High Speed (ISDN, etc...)"
9 == "Other"
17   6 (Char)   monitor
1 == "14 in."
2 == "15 in."
3 == "17 in. or greater"
4 == "Laptop"
18   6 (Char)   ram
1 == "< 8"
2 == "8 - 12"
3 == "> 12"
19   6 (Char)   cpu
1 == "386"
2 == "486"
3 == "pentium"
4 == "pentium pro"
9 == "other"

MessageType : 315 (0x13b)
MessageName : ChangeMembershipProfileStatus
Description :
NumDataFields : 2
---------------
Index   DataType   Description
-----   --------   -----------
0   1 (Int) changeMembershipProfileStatus
0 == Fail silently?
1 == Success?
2 == Nickname already in use
0x78 == Obscenity
0x7A == ??? (Failed)
1   7 (String)

MessageType : 316 (0x13c)
MessageName : SpecialChat?
Description :
NumDataFields : 12
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)
1   7 (String)
2   7 (String)
3   7 (String)
4   4 (Short)
5   4 (Short)
6   6 (Char)
7   6 (Char)
8   6 (Char)
9   6 (Char)
10   6 (Char)
11   6 (Char)

MessageType : 317 (0x13d)
MessageName :
Description :
NumDataFields : 0
---------------
Index   DataType   Description
-----   --------   -----------
(Intentionally left blank)

-----------------------------------
***********************************
-----------------------------------

MessageType : 401 (0x191)
MessageName : AcceptRoomJoin? (or game join?)
Description :
NumDataFields : 14
---------------
Index   DataType   Description
-----   --------   -----------
0   1 (Int)
1   1 (Int)
2   1 (Int) maxPlayers?
3   1 (Int)
4   1 (Int)
5   1 (Int)
6   1 (Int)
7   1 (Int)
8   1 (Int)
9   1 (Int)
10   1 (Int)
11   1 (Int)
12   1 (Int)
13   1 (Int)

MessageType : 402 (0x192)
MessageName :
Description : (Unblocks the clients) [ *** ]
NumDataFields : 2
---------------
Index   DataType   Description
-----   --------   -----------
0   1 (Int) numGamesInRoom
1   1 (Int) numPlayersInRoom

MessageType : 403 (0x193)
MessageName :
Description :
NumDataFields : 7
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)   roomName?
1   1 (Int) (Unused)
2   1 (Int) (Unused)
3   1 (Int) (Unused)
4   1 (Int) (Unused)
5   7 (String)   (Unused)
6   1 (Int) (Unused)
[**Warning**: Games reads 6 int fields into local variables]
[Note: The "extra" field is also unused]

MessageType : 404 (0x194)
MessageName :
Description :
NumDataFields : 3
---------------
Index   DataType   Description
-----   --------   -----------
0   1 (Int)
1   7 (String)
2   1 (Int)

MessageType : 405 (0x195)
MessageName :
Description :
NumDataFields : 1
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)

MessageType : 406 (0x196)
MessageName :
Description : (Removes a node)
NumDataFields : 1
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)

MessageType : 407 (0x197)
MessageName : Invitation
Description :
NumDataFields : 4
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)   gameName
1   1 (Int)
2   1 (Int)
3   7 (String)   playerName

MessageType : 408 (0x198)
MessageName : InvitationResponse
Description : Returns a response as to whether or not an
invitation was accepted or rejected.
NumDataFields : 2
---------------
Index   DataType   Description
-----   --------   -----------
0   1 (Int) bAccepted (1 == accepted, otherwise == declined)
1   7 (String)   playerName

MessageType : 409 (0x199)
MessageName : GameJoinRequest
Description :
NumDataFields : 4
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)
1   1 (Int)
2   1 (Int)
3   7 (String)

MessageType : 410 (0x19a)
MessageName : GameJoinRequestResponse
Description :
NumDataFields : 1
---------------
Index   DataType   Description
-----   --------   -----------
0   1 (Int)

MessageType : 411 (0x19b)
MessageName : AddPlayerToPlayerList/JoinGame?
Description : (Move/add/remove player)
NumDataFields : 4
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)
1   1 (Int)
2   1 (Int)
3   7 (String)

MessageType : 412 (0x19c)
MessageName :
Description :
NumDataFields : 4
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)
1   1 (Int)
2   1 (Int)
3   7 (String)   playerName (of who?)

MessageType : 413 (0x19d)
MessageName :
Description :
NumDataFields : 1
---------------
Index   DataType   Description
-----   --------   -----------
0   1 (Int)

MessageType : 414 (0x19e)
MessageName :
Description :
NumDataFields : 3
---------------
Index   DataType   Description
-----   --------   -----------
0   1 (Int)
1   7 (String)
2   8 (Buffer)

MessageType : 415 (0x19f)
MessageName :
Description :
NumDataFields : 3
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)
1   1 (Int)
2   1 (Int)

MessageType : 416 (0x1a0)
MessageName :
Description :
NumDataFields : 2
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)
1   7 (String)

MessageType : 417 (0x1a1)
MessageName :
Description :
NumDataFields : 1
---------------
Index   DataType   Description
-----   --------   -----------
0   1 (Int)

MessageType : 418 (0x1a2)
MessageName :
Description :
NumDataFields : 3
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)
1   1 (Int)
2   7 (String)

MessageType : 419 (0x1a3)
MessageName :
Description :
NumDataFields : 4
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)
1   1 (Int)
2   1 (Int)
3   7 (String)

MessageType : 420 (0x1a4)
MessageName :
Description :
NumDataFields : 4
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)
1   1 (Int)
2   1 (Int)
3   7 (String)

MessageType : 421 (0x1a5)
MessageName :
Description :
NumDataFields : 4
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)
1   7 (String)
2   7 (String)
3   1 (Int)
[ **WARNING**: Code processes 2 strings and 2 ints ]

MessageType : 422 (0x1a6)
MessageName :
Description :
NumDataFields : 4
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)
1   7 (String)
2   7 (String)
3   1 (Int)

MessageType : 423 (0x1a7)
MessageName :
Description :
NumDataFields : 2
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)
1   1 (Int)

MessageType : 424 (0x1a8)
MessageName :
Description :
NumDataFields : 2
---------------
Index   DataType   Description
-----   --------   -----------
0   1 (Int)
1   1 (Int)

-----------------------------------
***********************************
-----------------------------------

MessageType : 501 (0x1f5)
MessageName : ConnectedToGameServer?
Description :
NumDataFields : 0
---------------
Index   DataType   Description
-----   --------   -----------
(Intentionally left blank)

MessageType : 502 (0x1f6)
MessageName :
Description :
NumDataFields : 1
---------------
Index   DataType   Description
-----   --------   -----------
0   1 (Int)

MessageType : 503 (0x1f7)
MessageName :
Description :
NumDataFields : 0
---------------
Index   DataType   Description
-----   --------   -----------
(Intentionally left blank)

MessageType : 504 (0x1f8)
MessageName :
Description :
NumDataFields : 0
---------------
Index   DataType   Description
-----   --------   -----------
(Intentionally left blank)

MessageType : 505 (0x1f9)
MessageName :
Description :
NumDataFields : 1
---------------
Index   DataType   Description
-----   --------   -----------
0   8 (Buffer)

MessageType : 506 (0x1fa)
MessageName :
Description :
NumDataFields : 0
---------------
Index   DataType   Description
-----   --------   -----------
(Intentionally left blank)

-----------------------------------
***********************************
-----------------------------------

MessageType : 601 (0x259)
MessageName : Login
Description : User Logs into the SIGS system.
The SIGS server should reply with info
needed after the initial join.
(Such as a list of rooms).
NumDataFields : 2
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)   userName
1   7 (String)   password

MessageType : 602 (0x25a)
MessageName : JoinRoom
Description : Message from client to server to join a room.
Server should reply with error code (message 303)
NumDataFields : 1
---------------
Index   DataType   Description
-----   --------   -----------
0   1 (Int) roomID

MessageType : 603 (0x25b)
MessageName : CreateRoom
Description : Message from client to server to create a room.
The server should create a new room (message 306)
or return an error (message 304)
NumDataFields : 6
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)   roomName
1   7 (String)   description
2   7 (String)   gameType (Ex: "Last One Standing")
3   1 (Int) maxPlayers
4   6 (Char)   boolUsePassword
5   7 (String)   password

MessageType : 604 (0x25c)
MessageName :
Description :
NumDataFields : 0
---------------
Index   DataType   Description
-----   --------   -----------
(Intentionally left blank)

MessageType : 605 (0x25d)
MessageName : CreateGame
Description : Message from client to server to create a game.
NumDataFields : 7
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)   gameName
1   1 (Int) maxPlayers?
2   1 (Int) maxPlayers?
3   1 (Int) (4th int of message 401)
4   1 (Int) (5th int of message 401)
5   1 (Int)
6   1 (Int)

MessageType : 606 (0x25e)
MessageName : Invitation?
Description :
NumDataFields : 4
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)
1   1 (Int)
2   1 (Int)
3   7 (String)

MessageType : 607 (0x25f)
MessageName :
Description :
NumDataFields : 2
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)
1   1 (Int)

MessageType : 608 (0x260)
MessageName :
Description :
NumDataFields : 4
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)
1   7 (String)
2   1 (Int)
3   1 (Int)

MessageType : 609 (0x261)
MessageName :
Description :
NumDataFields : 2
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)
1   1 (Int)

MessageType : 610 (0x262)
MessageName :
Description :
NumDataFields : 3
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)
1   1 (Int)
2   7 (String)

MessageType : 611 (0x263)
MessageName :
Description :
NumDataFields : 2
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)
1   1 (Int)

MessageType : 612 (0x264)
MessageName : SearchForPlayer
Description : (SIGS->Find opponent...)
NumDataFields : 1
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)   playerName (to search for)

MessageType : 613 (0x265)
MessageName :
Description :
NumDataFields : 1
---------------
Index   DataType   Description
-----   --------   -----------
0   4 (Short)

MessageType : 614 (0x266)
MessageName :
Description :
NumDataFields : 0
---------------
Index   DataType   Description
-----   --------   -----------
(Intentionally left blank)

MessageType : 615 (0x267)
MessageName :
Description :
NumDataFields : 0
---------------
Index   DataType   Description
-----   --------   -----------
(Intentionally left blank)

MessageType : 616 (0x268)
MessageName : RequestSIGSVersionCheck
Description :
NumDataFields : 2
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)   Game/RegionString
1   7 (String)   GameVersionString

MessageType : 617 (0x269)
MessageName : RequestSIGSUpdate
Description :
NumDataFields : 0
---------------
Index   DataType   Description
-----   --------   -----------
(Intentionally left blank)

MessageType : 618 (0x26a)
MessageName : ViewPlayers
Description : Message from client to Lobby Server to view
the players in a room.
NumDataFields : 1
---------------
Index   DataType   Description
-----   --------   -----------
0   1 (Int) roomID

MessageType : 619 (0x26b)
MessageName :
Description :
NumDataFields : 0
---------------
Index   DataType   Description
-----   --------   -----------
(Intentionally left blank)

MessageType : 620 (0x26c)
MessageName : NewMember
Description : New member info submitted by user to SIGS when
choosing "New Member" at the Login screen.
NumDataFields : 21
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)   memberName
1   7 (String)   realName
2   7 (String)   password (Set to "PASSWORD", given by email)
3   7 (String)   address1
4   7 (String)   address2
5   7 (String)   city
6   7 (String)   state
7   7 (String)   country
8   7 (String)   postalCode
9   7 (String)   emailAddress
10   7 (String)   internetService ("Other")
11   7 (String)   ipAddress? (of what?)
12   4 (Short)   boolCD_ROM (0 == No CD, 1 == CD)
13   4 (Short)   boolMicrophone (0 == No Mic, 1 == Mic)
14   1 (Int)
15   6 (Char)   age
1 == "< 7"
2 == "7 - 12"
3 == "13 - 18"
4 == "19 - 25"
5 == "26 - 40"
6 == "41 - 54"
7 == "55+"
99 == "My Secret"
16   6 (Char)   gender
1 == "Male"
2 == "Female"
9 == "My Secret"
17   6 (Char)   connectionSpeed
1 == "2400"
2 == "9600"
3 == "14,400"
4 == "28,800"
5 == "High Speed (ISDN, etc...)"
9 == "Other"
18   6 (Char)   monitor
1 == "14 in."
2 == "15 in."
3 == "17 in. or greater"
4 == "Laptop"
19   6 (Char)   ram
1 == "< 8"
2 == "8 - 12"
3 == "> 12"
20   6 (Char)   cpu
1 == "386"
2 == "486"
3 == "pentium"
4 == "pentium pro"
9 == "other"

MessageType : 621 (0x26d)
MessageName :
Description :
NumDataFields : 2
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)
1   7 (String)

MessageType : 622 (0x26e)
MessageName : UpdateMembershipProfile
Description : Member info submitted by user to SIGS when updating
their membership profile.
NumDataFields : 23
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)   memberName
1   7 (String)   realName
2   7 (String)   password
3   7 (String)   address1
4   7 (String)   address2
5   7 (String)   city
6   7 (String)   state
7   7 (String)   country
8   7 (String)   postalCode
9   7 (String)   emailAddress
10   7 (String)   internetService ("Other")
11   7 (String)   ipAddress? (of who?)
12   7 (String)   playerName
13   7 (String)   password2
14   4 (Short)   boolCD_ROM (0 == No CD, 1 == CD)
15   4 (Short)   boolMicrophone (0 == No Mic, 1 == Mic)
16   1 (Int)
17   6 (Char)   age
1 == "< 7"
2 == "7 - 12"
3 == "13 - 18"
4 == "19 - 25"
5 == "26 - 40"
6 == "41 - 54"
7 == "55+"
99 == "My Secret"
18   6 (Char)   gender
1 == "Male"
2 == "Female"
9 == "My Secret"
19   6 (Char)   connectionSpeed
1 == "2400"
2 == "9600"
3 == "14,400"
4 == "28,800"
5 == "High Speed (ISDN, etc...)"
9 == "Other"
20   6 (Char)   monitor
1 == "14 in."
2 == "15 in."
3 == "17 in. or greater"
4 == "Laptop"
21   6 (Char)   ram
1 == "< 8"
2 == "8 - 12"
3 == "> 12"
22   6 (Char)   cpu
1 == "386"
2 == "486"
3 == "pentium"
4 == "pentium pro"
9 == "other"

MessageType : 623 (0x26f)
MessageName :
Description :
NumDataFields : 1
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)

MessageType : 624 (0x270)
MessageName :
Description :
NumDataFields : 2
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)
1   7 (String)

MessageType : 625 (0x271)
MessageName : SendCustomServerMessage
Description :
NumDataFields : 1
---------------
Index   DataType   Description
-----   --------   -----------
0   8 (Buffer)

MessageType : 626 (0x272)
MessageName : RequestGameVersionCheck
Description :
NumDataFields : 2
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)   GameVersionString
1   7 (String)

MessageType : 627 (0x273)
MessageName : SetGameState / LeaveChatRoom? / LeaveGame? No
Description : Note: The meaning of Value depends on Parameter
For PARAM_JOIN_PERMISSION:
   1 - Nobody can join
2 - No approval required
3 - Any one player may allow
   4 - Only captain may allow
   5 - Only game owner may allow
   6 - Majority vote required (not yet implemented)
   7 - Everyone must approve (not yet implemented)
For PARAM_INVITE_PERMISSION:
   1 - Only owner may invite (not yet implemented)
   2 - Only captain may invite (not yet implemented)
   3 - Any player may invite
   4 - Anyone in room may invite (not yet implemented)
NumDataFields : 3
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)   gameName
1   1 (Int) parameter (PARAM_JOIN_PERMISSION, PARAM_INVITE_PERMISSION, PERAM_WATCH_PERMISSION)
2   1 (Int) value

MessageType : 628 (0x274)
MessageName :
Description :
NumDataFields : 2
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)
1   1 (Int)

MessageType : 629 (0x275)
MessageName :
Description :
NumDataFields : 3
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)
1   1 (Int)
2   1 (Int)

MessageType : 630 (0x276)
MessageName :
Description :
NumDataFields : 4
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)
1   1 (Int)
2   1 (Int)
3   7 (String)

MessageType : 631 (0x277)
MessageName : Complaint
Description : User submitted complaint to SIGS about another user
or the SIGS system itself.
Note: The field offender will be "SIGS" if the user
chooses to submit a complaint about SIGS rather than
another user.
Note: the client will append the last 20 lines of
Room chat to the complaint before sending.
This applies even for complaints about SIGS.
NumDataFields : 2
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)   offender (playerName of offender)
1   7 (String)   complaint

MessageType : 632 (0x278)
MessageName :
Description :
NumDataFields : 1
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)

MessageType : 633 (0x279)
MessageName :
Description :
NumDataFields : 1
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)

MessageType : 634 (0x27a)
MessageName :
Description :
NumDataFields : 1
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)

-----------------------------------
***********************************
-----------------------------------

MessageType : 701 (0x2bd)
MessageName : ChatMessage
Description : Send a chat message to a chat room.
The chat message is NOT automatically echoed
to the chat room's chat display.
NumDataFields : 2
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)   sourcePlayerName
1   7 (String)   chatMessage

MessageType : 702 (0x2be)
MessageName : PrivateChatMessage
Description : Sends a private chat message to the destination
player.
The chat message is automatically echoed to the
chat room display as a sent private message.
NumDataFields : 3
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)   destPlayerName (Unused by client)
1   7 (String)   sourcePlayerName
2   7 (String)   chatMessage

MessageType : 703 (0x2bf)
MessageName : [Send]Message
Description : Transmits a generic message to all other players
NumDataFields : 1
---------------
Index   DataType   Description
-----   --------   -----------
0   8 (Buffer)

MessageType : 704 (0x2c0)
MessageName : [Send]PointMessage
Description : Transmits a generic message to a specific player
NumDataFields : 3
---------------
Index   DataType   Description
-----   --------   -----------
0   1 (Int)
1   1 (Int)
2   8 (Buffer)

-----------------------------------
***********************************
-----------------------------------

MessageType : 801 (0x321)
MessageName : SysOpMessage
Description : Message from a SysOp (to the entire system)
NumDataFields : 1
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)   message

MessageType : 802 (0x322)
MessageName : PrivateSysOpMessage
Description : Priavte message from a SysOp to a specific user
NumDataFields : 2
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)   message
1   7 (String)   (Unused)

MessageType : 803 (0x323)
MessageName : NewsAndInfo
Description : Creates a popup window displaying the news/info
NumDataFields : 3
---------------
Index   DataType   Description
-----   --------   -----------
0   1 (Int) messageTimeStamp
1   7 (String)
2   7 (String)   newsAndInfo

MessageType : 804 (0x324)
MessageName :
Description :
NumDataFields : 1
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)

-----------------------------------
***********************************
-----------------------------------

MessageType : 901 (0x385)
MessageName : ConnectionSuccessful
Description :
NumDataFields : 2
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)   gameServerName
1   1 (Int) portNum

MessageType : 902 (0x386)
MessageName : GameRequestedNotFound
Description :
NumDataFields : 0
---------------
Index   DataType   Description
-----   --------   -----------
(Intentionally left blank)

MessageType : 903 (0x387)
MessageName : SigsDllRequiresUpdate
Description :
NumDataFields : 2
---------------
Index   DataType   Description
-----   --------   -----------
0   7 (String)   newSigsDllVersion
1   1 (Int) newSigsDllSize

MessageType : 904 (0x388)
MessageName :
Description :
NumDataFields : 1
---------------
Index   DataType   Description
-----   --------   -----------
0   1 (Int)

MessageType : 905 (0x389)
MessageName :
Description :
NumDataFields : 1
---------------
Index   DataType   Description
-----   --------   -----------
0   8 (Buffer)

MessageType : 906 (0x38a)
MessageName :
Description :
NumDataFields : 0
---------------
Index   DataType   Description
-----   --------   -----------
(Intentionally left blank)

MessageType : 907 (0x38b)
MessageName : GameRequiresUpdate
Description :
NumDataFields : 3
---------------
Index   DataType   Description
-----   --------   -----------
0   1 (Int) ( < 0 or message is ignored)
1   1 (Int) downloadSize
2   4 (Short)   boolRequiredUpdate (0 == Optional, non-zero == Required)

Title: SIGS/WON
Post by: Highlander on March 16, 2007, 06:39:02 PM

Now, I don't understand from exceptionally little to nothing in coding.

However, I do remember some project a while back to try and reproduce the original SIGS program.

Is anyone working on that now ?

Title: SIGS/WON
Post by: Arklon on March 16, 2007, 06:40:32 PM

Quote

Now, I don't understand from exceptionally little to nothing in coding.

However, I do remember some project a while back to try and reproduce the original SIGS program.

Is anyone working on that now ?

Hacker has a Hamachi/WON (yes, it'll replace both) replacement WIP, but I'm not sure if he's been able to work on it much lately.

Title: SIGS/WON
Post by: Hooman on March 17, 2007, 04:38:52 AM

I've been working on a SIGS server replacement off and on for quite a while now. (OK, more off than on, I think it's been about 3 and a half years now since I started any serious work). That might have been what you heard about. Hacker has done some stuff too, but from a much different perspective. I think he looked into replacing the client end too.

I've attached some source code of something I had worked on a while back. I don't remember how complete the example code is though, but it should be enough to connect and possibly quit without crashing or locking up (unless you try to use some functionality I never got around to writing code for). I should also point out that this is an extremely simplistic test with hardcoded responses, so don't expect it to actually work. It just sort of appears to work a little if you don't really do anything. It was mainly written to test things out and to try and help discover how the protocol works. I have more advanced code, but I think I left it in an unstable state the last time I worked on it.

To use the code, be sure to change Sierra.ini in the Windows folder. You need to change/add the part that looks like:

Code: [Select]

[SIGS]
ValidateIP=<insertIPAddressHere>

I just set it to a local IP address on my LAN where I was running the test server. You also need to run two copies of it (one on port 7800, and one on port 7801) to really get it working. (The initial connect is on port 7800, and might be hardcoded into the game, I can't quite remember now, and the second port (or any subsequent ports) are whatever you told the client during the earlier connect phase).

Title: SIGS/WON
Post by: Arklon on March 17, 2007, 08:54:44 AM

No, what I heard about was specifically Hacker's work. From the looks of it, his method's more complete (at least the method idea itself).

Title: SIGS/WON
Post by: Hooman on March 17, 2007, 05:52:02 PM

OK. Is it the same thing Highlander heard about?

There are a number ways of trying to get a SIGS like system up and running again. They all have advantages and disadvantages. There are also other issues with the network code that could use some work. I sort of view the stuff I posted as leading to one of the most basic approaches. The most drastic being to completely rewrite the game.

With the stuff I'm working on, a client from an original OP2 CD (with no patching) could potentially connect and use the system, but couldn't play games from behind a router due to limitations in the OP2 network code, which has nothing to do with the SIGS system. They would have no trouble joining rooms and chatting though, and should be able to play if they're not behind a router. The nice thing about this method is we could use the built in update system to distribute patches and updates to OP2. These patches could include fixes for things like the NAT issues with home routers so people could play from behind them, and could also include other updates, such as a complete replacement to the SIGS/WON code (client side included). We would need a way to point the client at the right server though. I think the default it looks for is "smc.sierra.com". This name doesn't seem to be in use when I tried to ping it, so maybe we could do some asking to get it pointed to a server we set up (seems a little unlikely though), or we could tell people to enter an IP of a server we setup into Sierra.ini in their Windows folder. So at worst, they would have to edit a text file with something like notepad, and wouldn't be required to mess with anything else or downloaded modified code that they might not trust (or have parents that won't allow them to do so). The difficulty with this method is there is no server code to analyse. We would have to figure out the protocol only from how the client responds to messages it receives, and messages it sends out.

The next method I see is to completely replace the client side of SIGS. This would require an update to be distributed to accomplish this. Either through a download from a webpage, or through the update system in the above method. We would then be free to use whatever network protocol we wanted. This would save us from having to figure out the SIGS protocol (or at least no more than the update part). We would however need to figure out how the user interface components work with OP2. This is probably a little easier, since we have existing code to analyse for this, and some (slightly depricated?) header files that describe this interface. It still looks like a fair bit of tough work, but at least we have source code for a completely working interface that we could analyse. Although, some parts of the interface are only used in response to network messages, so knowledge of the above may help in developing a proper new interface.

Then you might consider various patches to handle certain issues like port forwarding, and NAT from home routers. This would appear to require patching beyond a simple SIGS server, although, it would help to have such a server available to perform some kind of punch through. Although, this is really quite an extension to the existing interface from what I can tell, and would require changes to more than just the SIGS network layer DLLs.

The next method I see is pretty much a complete rewrite of the whole game, including a new game server, protocol, and interface. It would allow us to remove the most number of bugs and issues, but would also take years to do.

Title: SIGS/WON
Post by: Arklon on March 17, 2007, 06:02:56 PM

I'm not sure which project Highlander is talking about. It could've been Martynd's project for all I know...

Hacker mentioned his method would be able to replace both WON and Hamachi (which also means no more port forwarding, either), and could implement automatic update checks easily. You'd need to ask him about the specifics of it. However, his method sounds like the best route to go. What you're working on seems to suggest a ton of reverse engineering, which would take a very long time... for pretty much the benefit of potentially being compatible with the Dynamix OP2 out of the box (though, we're not going to be able to use smc.sierra.com, so it's pointless).
OP2's 10th anniversary is coming up very soon, and it'd be really nice to have some things like this completed by then.

Title: SIGS/WON
Post by: Hooman on March 18, 2007, 01:53:09 AM

There's still the simple Sierra.ini edit to point the client to the server. Not quite automatic for the user, but a simple and easy fix to get things working.

Also, SIGS on it's own, or any replacement system won't fix the port forwarding issue. The problem being that the game's underlying network protocol is completely seperate from the SIGS network protocol (or any similar replacement). What we'd have to do is patch more network code in OP2, sort of like the NAT-fix patch, and that would eliminate port forwarding for people trying to join games. There would still need to be a host with correct port forwarding though. Such as the person hosting the game, although, that responsibility could be passed on to another server that is assumed to have correct port forwarding setup, or is not behind a NAT router. If there was a working SIGS system, then you could potentially patch the game to get info from the server and avoid any player having to setup port forwarding, even by the host, but that would require substantially more work on the network code. (ie. pass the responsibility onto a SIGS server)

I think the easiest short term solution is more network code patching to limit the port forwarding requirement to the game host. With that in place (and the NAT fix in place), there would be no need for things like Hamachi. Plus, if it was done right, it could be extended to pass the responsibility onto a system like SIGS, if they're using it, or fallback on the game host for correct port forwarding if they're not.

Title: SIGS/WON
Post by: Arklon on March 18, 2007, 10:04:23 AM

Quote

There's still the simple Sierra.ini edit to point the client to the server. Not quite automatic for the user, but a simple and easy fix to get things working.

But people would have to visit this site to find out about that, and then they might as well download our version of OP2. Again, it'd be pointless to attempt to make this compatible with the Dynamix OP2 out of the box.

Hacker said that he'd implement NAT punch-through (which is what Hamachi does) in his replacement.
You'll need to ask him for more information, because that's really all I know.

Title: SIGS/WON
Post by: Eddy-B on March 18, 2007, 02:46:04 PM

Hooman !!
it seems you've been quite busy lately !
Way to g0 !

Title: SIGS/WON
Post by: Hooman on March 18, 2007, 07:50:05 PM

Sadly this info isn't all that recent. I've done a little touch up when posting, but this is mostly back from december or earlier. I just figured I've got so many unfinished threads in this forum that I should get back to posting and try to finish them.

Also, I don't see why it's pointless to be compatible with an out of the box version. People like me are weary of things like the OP2 download. I chose not to run it until I had verified why each and every byte was changed, and even then, only because the version differences introduced forced me to use it to be able to play with other people. (Btw, the old No-CD patch was really sick, and changed a lot of things it didn't need to. They just sort of butchered the exe until eventually it worked.)

Granted, if it requires a lot of extra work, then you're probably better off doing something else. But from what I've examined of the code so far, it doesn't seem like it would really save any time to create new client DLLs. You'd just be moving the problem from understanding the network protocol, to understanding how those DLLs interface with the game. We can find a little more info on the interface, but the project of replacing both the client and the server is a lot bigger than replacing only the server. I suspect either way we go, it'll probably take about the same amount of time. In which case my question is, why not bother to be compatible with the CD version?

Besides, I'd much rather look at the network code than the interface code. :)

Also, I should emphasize that getting a game server running, and dealing with port forwarding (using something like NAT punchthrough) are completely different problems. Solving one doesn't automatically solve the other. You can use a game server to help out, by matching up the ports for the clients, but really that problem is a seperate patch. A game server by either method requires no modifications to Outpost2.exe, but the portforwarding issue does.

Title: SIGS/WON
Post by: Arklon on March 18, 2007, 07:59:57 PM

Quote

Also, I don't see why it's pointless to be compatible with an out of the box version. People like me are weary of things like the OP2 download. I chose not to run it until I had verified why each and every byte was changed, and even then, only because the version differences introduced forced me to use it to be able to play with other people. (Btw, the old No-CD patch was really sick, and changed a lot of things it didn't need to. They just sort of butchered the exe until eventually it worked.)

... Not even checksum errors occur to you as a problem? Even if you were somehow able to bypass the checksum errors, just because of the differences between them (even minor, even techs being arranged differently though essentially being the same would cause this), they will desync and crash. And very few people here are wary of our OP2.

Title: SIGS/WON
Post by: Highlander on March 18, 2007, 11:46:01 PM

I don't know which project I am talking about.. didn't know there were more than 1 ongoing process.

Anyways, just my opinion, but I think this project should be given some more priority. Though again, I respect you code guys for not having the time for it, it's just my personal view.

Hooman, you seem to have two idea on how to get this to work(using the old SIGS/WON and make a new one). From what I gather, it would take pretty much the same time ? If that is the case, it would perhaps be better to write our own, since that could be made more flexible and could be easier changed at a later stage if needed.

Title: SIGS/WON
Post by: Hooman on March 19, 2007, 01:33:34 AM

I've already thought of checksum errors, and no, I don't consider them much of an issue. Not any more of an issue then they already are. Especially if checksums only get changes across different versions. The server will know the version of the client from when it connects. It also has control over which games and rooms you can join. Simple solution, don't let them join a game if they have a different client version than the host.

It's not exactly perfect though, since people can muck with their files rather than simply "upgrade" to a new version, but we currently don't have any built in way to detect that until you try to start a game and it fails, tells you, and kicks everyone out. Basically we are no worse off. (Origianl CD installs have a different version number than the downloadable version). Maybe even a little better off since the SIGS server can send back good error messages, and also inform the client of which hosted games are what versions. Then people can always choose to switch versions depending on the availability of games being played. (Displaying checksum info would require a bit of a hack, and fits in a little better with the client replacement idea).

Another thought is that by using the original SIGS protocol, you could also potentially support other Sierra games that were released and uses it. Probably not a big point for anything here though. I never play any of the other games, although I think Homeworld was one. Probably more people played that game though, so who knows, a working game server for a number of Sierra games might attract more people to this game. There is a way to advertise stuff on SIGS.

As for the time concern, I figure it would probably take less time to make a compatible server. One big reason is that I already worked on this idea, and have knowledge of it. Another big reason being that I'm much more interested in working on understanding the existing network protocol than working with raw Windows GUI function calls, and the typical message passing system. Also, knowledge of one possible way to make a replacement can help determine knowledge about how to write the other type of replacement. I find the way the interface between the game and network DLLs to be pretty obscure and non intuitive, so I prefer to work on the system from the network side. Eventually those network packets cause interactions across that interface, and the meaning of those interactions becomes a lot clearer.

Also, understanding how the network protocol works is something I can reasonably do on my own (given enough free time). Writing the server given a fairly complete specification is also potentially something I can do on my own (at least a simple one with basic functionality). Trying to write both a client and server sounds like too big of a project for me to finish on my own. Especially since I have little interest in writing the kind of code required for a new client. Not to mention I've only ever seen Cynex demonstrate an ability for some of the code needed for a new client, and I don't think I've seen him around in years. Windows GUI work in C++ is not my idea of fun. I'm also not often on at the same time as the other programmers, and can't always reliably visit the forums or IRC (potentially for months at a time), so it'd be difficult to coordinate a project with someone else.

A new client also doesn't actually fix the existing problems on it's own. It just moves trying to figure out the network protocol to figuring out the interface. Things like portforwarding and NAT wouldn't be solved by a new client alone. It'd just be a little easier to add support into a new client to help out. The real problem is inside Outpost2.exe. That's where the main problem is that splits players between Ham and direct connect. This code is completely independing of any game server system. We'd have to figure out how to fix that code to even consider adding support code (either in a patch, or in a new client) that can further help matching up players from behind a router.

One reason why I'm not working on the SIGS project currently is because I'm busy taking another look at the Outpost2.exe network code. I figure that's where the bigger problem is. Having a new game server would just be a nice convenience, but fixing the Outpost2.exe code would allow more people to play without the assistance of Ham. (Although, the game server would allow for a more complete solution later on that could completely eliminate the need for HAM if properly coupled with the Outpost2.exe network code fix). The amount of code to analyse is substantially more than what was required for the NAT-fix patch though. To make the NAT fix patch (dealing only with a wrong IP), we only needed to find a single point where an IP was packaged into a packet. To fix the port forwarding issue, we need to take a look at all the bindings to network addresses as a whole, try to eliminate a hardcoded port number from most of the bindings, and make sure it's done in a way that an ordering of packets still makes sense and allows clients to connect from behind NAT. Currently, the ordering of the way packets are sent and received won't allow the client to work by simply adjusting the bind calls. What might be possible, is to share the same port for different parts of the protocol. This might confuse the client though if it gets traffic on the port at the wrong time. Like if someone tries to join a game after it has started. Another possibility is to introduce some kind of thin wrapping layer, although, hopefully that isn't necessary. Especially since it introduces more incompatibilities than needed. If done right, an unpatched copy might still work with a patched copy if they're of the same version for everything else.

Btw, you may have noticed I like to maintain compatibility with older versions in most things that I do.

Title: SIGS/WON
Post by: BlackBox on March 19, 2007, 02:49:32 PM

Well, (not sure if I mentioned this to many people) I did figure out the interface between the game and the SIGS DLL. Much of it came from a header file which was part of the Homeworld source code. I did have to make a few modifications because the API was slightly different (a few functions took different number / types of parameters, etc).

Anyway, after the game calls the DLL telling it to initialize the system (this is the point at which a separate thread is spawned {everything is done in-process} so that SIGS can run without interfering with the game, and the login dialog is initially displayed) OP2 will repeatedly poll the DLL to find out if a game has been started, if SIGS has been closed, so on. When it detects that a game was started, it will make more calls to the DLL to determine what type of game it is, and how many players are in the game. (This is where SIGS is slightly different from TCP/IP games. There is no "find session" feature like TCP/IP that uses different ports, and all players are joined to the game at once (on the OP2 side). Presumably the players were gathered together in some "SIGS lobby" and then dropped to the OP2 game settings window as soon as there were enough players / the game was "started" from the SIGS side. Also, the game will be automatically canceled should all players quit/be ejected except for the host).

Because the player information must all be known beforehand, after OP2 gathers the information about game type and number of players, it queries the DLL for each player to retrieve the player name as well as their IP and port number that is being used for their game session.

As you probably already know, port 47800 is used as the incoming port for all game data once users have gotten to the game settings window. (The lower ports 47776 / 47777 and so on are only used to enable others to broadcast for sessions and negotiate joining the game). All other 'normal' traffic is sent to 47800.

Now, the reason port forwarding is necessary is because this port number is essentially hardcoded for TCP/IP games. This makes playing through NAT without portforwarding essentially impossible because it is impossible to tell the game what port data must be sent to in order to traverse the NAT gateway to the remote client.

NAT punch through works like this: A client (let's call it client A) sends data to a master server that is not subject to NAT. The master server records the source IP and port of the transmission and stores it. Another client (let's say client B) connects to the same master server and their IP:port information is recorded in the same manner. When client A wants to connect directly to client B, it asks the server for client B's stored information. The server will give client A that information which enables it to connect directly. This works because the port that client B originally used to connect to the server has been opened by the NAT box on B's side. When data comes into that port, the NAT box knows where to send it on the internal network because the machine on the LAN originally attempted to send data out through that port.

Of course, this is idealized and there are some extra steps that need to be taken in the real world (namely, client B must attempt a connection to client A because the NAT box usually only permits traffic from IP's that an internal machine has already sent data to.. this is called a restricted cone NAT, but I won't get any deeper into it)

Anyway, to come back to the subject at hand, SIGS is essentially able to tell the game what port to send data to for each of the remote clients. If the SIGS server supplies this information to the client, then it is able to perform NAT punch through.

There are a couple difficulties with this method. Since the IP and port of the client as seen from the internet side must be known beforehand to the server (otherwise the other clients have no way to determine what it is), the game and the SIGS system must use the same port for communication. There are two ways I can think of that could solve this:

Method #1. SIGS gets out of the way after the game is started. The SIGS client will not send or receive data until the game is finished (and this is indicated to the client when the game notifies it that the game has finished). The only problem with this method is that it makes it impossible for the client to communicate with the server while a game is going on. (for example, chat messages, server pings, user entered/left, sysop messages, so on).

Method #2. This method doesn't seem as nice but it seems like it would work better (at least taking care of the limitations seen in the first method). The client would listen for packets on local addresses (i.e 127.0.0.1:xxxx) and give these addresses to the game. In this way, the client would have to act as a sort of relay between the game and the actual players (the client would need to establish the peer connections itself of course, and perform the punchthrough itself). This would mean that the game data would probably get tunneled inside of another protocol (again, because you're having to use the same channel for communication to both perform the NAT punchthrough as well as the sending/receiving of game data). The only drawback that I can see to this, is that the Net Stats window in the game would show incorrect IP addresses (since the game is technically communicating with the local machine), although that's not that big of a deal (I never saw a need for it anyway).

Of course, all of this requires a custom client as well as server. I still think this would be faster than to attempt to figure out the SIGS protocol (and on top of that, you still need to figure out how to perform the NAT punchthrough because the client can't do it for the game), seeing as we already have the exact interface that the game uses between it and the network DLLs.

I have in fact written a surrogate client DLL that interfaces with an IRC client to connect to games (as a test). It only works on a LAN / without NAT routers however since it didn't do any sort of punchthrough. It simply proves that it is possible to create a game session using replacement SIGS software.

----

Now, this is where I have to start to disagree with people. First thing I would say, what good is it to maintain compatibility with the original SIGS version as well as the original CD version of Outpost 2? It already isn't very possible since the EXE's are different. For example, the cheats were patched over so it is impossible to use them (and there is perfectly good reason for that). If two players used different EXEs, they would fail the checksum check when the game started. If the checksums were patched so that the game reported the same checksum for both files (even though they were not the same), the game would desync as soon as a player typed a cheat (since one game would process it differently than the other game).
There are plenty of other patches that make it worthwhile to use a different EXE (GDI drawing patch, NAT hosting patch, CD patch to name the most important ones).

As far as changing the version number goes, it already makes it impossible to join the game via TCP/IP. (The player will be kicked out automatically because the version numbers are compared on connect)

Furthermore, people would still need to have the new maps in order to play. As far as the 'being wary of updates' goes, wouldn't the same apply to missions? They are executable after all.

SIGS distributed game updates as well through its system (and I believe via HTTP). Unless this data stream was encrypted (I doubt it) someone could modify it as it passed through the internet (or you could use other attacks, i.e. poisoning a DNS cache to force them to connect to a totally different server and get malicious code that way).

Any way possible you are pretty much forced to update the game.

Furthermore as far as the reasoning goes about INI updates vs. DLL updates, either way, they'd still need to find our site to know to do either. Unless we could gain control of the domain name smc.sierra.com which isn't likely (and even less likely that anyone is still attempting to connect to SIGS with the game after all these years). Since an update is necessary in the first place, it would be just as easy to add replacement SIGS DLLs to this update.

I like backwards compatibility as well, but in this case the benefits of not being compatible majorly outweigh the drawbacks.

Title: SIGS/WON
Post by: Hooman on March 19, 2007, 09:31:37 PM

Hmm, sounds like you might be further ahead than I expected. Have you actually gotten into a game back in Outpost2? What kind of user interface did it have exactly? How close to usable is it?

Btw, it'd be nice to document those changes somewhere. I noticed those header files weren't quite up to date at one point, but never really bothered to compare them all that closely. They seemed largely accurate which was good enough for my purposes with them.

As for the compatibility, I don't much care about compatibility of clients of different versions so much as compatability of clients of the same version within the same SIGS system (for this project anyways). That is, it'd be nice if the system worked for both new and old clients, even if the clients didn't necessarily all agree with each other.

I realize the exe file is currently not compatible. Although, keep in mind that they are very close in terms of the cheat patch. The cheat patch could also have been done differently. There was some discussion back in the day about possible ways to do it without breaking compatibility, but the simple way that broke compatibility was much quicker and easier to do (and we only had a few days before the update was to be released). We could have instead kicked a client that was trying to cheat. The difference in compatibility only appears when a cheat code was typed, so we could have just added appropriate code there in place of the cheat code. Kick the offending client and resync the remaining players. Then typing a cheat code would be equivalent to them clicking the X button. (My only concern being collisions and that the hashing might detect some random valid string you sent to someone as a cheat).

The current NAT fix also breaks compatibility. I also believe it'd be unreasonably hard to fix the port forwarding issue without breaking compatibility. It'd be unreasonable to do without those fixes just to stay compatible, since the old versions are pretty much unusable to many people because of the problems.

So yeah, because of those two main patches (the exe checksum is trivial to fix) I see little reason to maintain compatibility across the different versions of the game. But I also don't see any real reason to disallow a method to work with the old version of the game. Keep in mind that either method (the new clients, or figuring out the existing protocol) can be used with either old or new versions of the game. It's just the a new client forces them to download new DLLs, and the other method doesn't. (Well, it'll work for both new and old versions of the game provided you don't make assumptions in a new client about the exe being patched in certain ways).

I guess another of my concerns besides compatibility, is to get things working while changing as little as possible. Especially if it involves updates to executable code. Changing a line in an ini file doesn't concern me as much as downloading new DLLs. It's also a lot friendlier to people on dialup.

I'm not too sure what you mean by an update being required anyways. Changing a line in a ini file doesn't exactly require a download.

And as for level downloads, some people might have noticed I'm either not very willing or slow to try out their levels. I generally only do so if I've compiled the source myself, and only after having inspected the source. Perhaps overly paranoid, but in many ways a safe habit to practice. I've spent a lot of time studying computer related security topics, and it seems a little silly for me to not practice it.

There's also the issue of scope creep. If you're going to change that much, it starts looking pretty tempting to me to go all the way. There are many little issues it'd be nice to see fixed, and the easiest and quickest way to fix them all is to just rewrite the whole game, game server and all. I've figured it should be done for quite some time now, but I don't have the time or motivation to really work on such a large project. Besides, my main interest here is that it gives me an excuse to toy with assembly and a chance to have fun reverse engineering something. If my main intention was to fix all the little bugs and problems, I'd have started rewriting the game long ago. But then I wouldn't have as much fun doing it, so the project would enevitably get abandoned long before it ever got finished. It's not like I'm getting paid here afterall. :P

Title: SIGS/WON
Post by: CK9 on March 20, 2007, 10:18:26 PM

I started reading through your notes up there, and it gave me indigestion >.<

keep up the good work hooman, hope you can accomplish what you're going for.

Title: SIGS/WON
Post by: Highlander on March 20, 2007, 10:22:12 PM

Hooman, I got 120 units of common ore on hand, and some more deposited in the bank ;)

I've read through all replies here, but truth is, much of it is above my head. Though 1 question still keeps popping into my head: Is there any way to make sure anyone, whether they are behind a router etc, play op2 ? (I assume there isn't, and if it is it will be hard to do since this solution hasn't been presented before)

However, both of are welcome to pick my mind if you have any questions about how the old WON system worked! I hope I still remember something ;)

Title: SIGS/WON
Post by: Hooman on March 21, 2007, 02:11:35 AM

Quote

I've read through all replies here, but truth is, much of it is above my head. Though 1 question still keeps popping into my head: Is there any way to make sure anyone, whether they are behind a router etc, play op2 ? (I assume there isn't, and if it is it will be hard to do since this solution hasn't been presented before)

To some extent yes. You could patch the network code in Outpost2.exe, and make it more conforming to the way most games work now that are playable from behind a router. It might require a fairly large change to the network code though. Doing it right would require more analysis. That was the project I mentioned I was looking into instead of working on the SIGS project. It hasn't been done because it's hard, but not so hard that it can't eventually be done.

What that project would likely accomplish is that only the host would need to forward ports (and only if they were behing a NAT router).

---

The extension to that idea, that does involve a game server, is to use the game server as a form of introducer. Then it'd be possible (but probably require properly patched network code in Outpost2.exe), to play games from behind a router without anyone having to forward ports, even the host. (Essentially you're using the game server like a host, and only the game server would need to have portfowarding setup, and only if it was behind a NAT router, which will certainly be the case).

Maybe that could be accomlished using the same patch, and a game server, or perhaps you'd need to write a more extensive patch that could make use of the game server. It all depends on how the two systems work, and how they work together.

---

One of the reasons why I wanted to look into SIGS originally, was that potentially no game patching would be required to play through a SIGS system, depending on how the game server worked. If the game server naturally acted enough like a host/introducer, then just writing the game server properly could have allowed you to play. From what I've seen though, this seems to be an unlikely case. Although, as of yet I don't think I can quite discount the possibility. The main part of the SIGS network protocol that I don't understand is for hosting and joining games. (Room joining and chat don't seem too complicated). The game hosting is the main part I'd need to figure out to really be able to answer that question. Or at least know more about how the SIGS client DLLs interface with the game to get something started.

But again, the SIGS network code is seperate from the Outpost2 network code, and I suspect the Outpost2 network code takes over at a point early enough that a game server couldn't work properly as an introducer. So, I don't think it would work, but I'm not currently absolutely sure. (Or have forgotten hard reasons why it wouldn't work).

---

Quote

However, both of are welcome to pick my mind if you have any questions about how the old WON system worked! I hope I still remember something

Yes, I would love to hear anything and everything you could tell me. Try to be very specific though. I attached some source code for a test server in an earlier post. There should be compiled componets included in the zip file, so you won't need a compiler to just try it out and see. If you have some coding knowledge and a compiler though, I encourage you to play around with it a bit and see if you can figure anything else out.

So yeah, try it out, refresh your memory on what the system was like, and maybe tell me a bit about how what I have differs from how the original system worked. In particular, I found myself wondering about the initial room join. I'm not really sure where the client is supposed to dump you when you first join. Did it make you join a room? Or just leave you at a list of rooms? I suspect it joins a room automatically, which is currently what happens.

Btw, don't expect switching rooms to work correctly. I just hardcoded responses from the server to get a quick test going. It doesn't actually parse the incomming packets properly and join the room you requested. :P Also, don't be surprised if the client locks up if you try searching for a player or something. I think I was too lazy to code in a response to that packet, so the client just waits forever expecting to get one back. :P

[Remember, Windows\Sierra.ini => set the server IP to something like "127.0.0.1", or "localhost", and then run both exe's in the zip file, then try to connect]

Title: SIGS/WON
Post by: alice on March 23, 2007, 12:27:53 PM

Quote

Offset   Message Offset Size Description
------ -------------- ---- -----------
0x0   -X- 4 Length prefix of following data   (Big Endian)
- - - - - - - - - - - - - - - - - - - - - -
0x4   0x0 4 MessageLength (Big Endian)
0x8   0x4 4 MessageType (Big Endian)
0xC   0x8 4 Flags? (MSB is either 1 or 9)   (Big Endian)
- - - - - - - - - - - - - - - - - - - - - -
0x10   0xC Variable   Message specific data. (*Some* data will be Big Endian)
...

Note: The "Flags?" value use is unknown, but values in the most significant byte
other than 1 or 9 cause the message to be discarded. The lower order bytes are
not checked in the comparison. Also, all values passed by the client seem to use
the value 1.

Are you sure the Flags field is Big Endian? Because in all of my packets, its:

Code: [Select]

01 00 00 00

Or maybe the length is wrong... I may end up just discarding that field anyway but I wasn't sure. :unsure:

Like in this example:

Code: [Select]

00 00 00 20 00 00 00 20 00 00 02 68 [01 00 00 00] 4F 75 74 70 6F 73 74 32 5F 55 53 00 33 2E 30 2E 33 2E 30 00

The part in brackets is the flag field. maybe I'm looking at it wrong :heh:

(Would've asked you about it on IRC, but you werent on)

Title: SIGS/WON
Post by: Hooman on March 23, 2007, 03:29:10 PM

Yes, because the code does endian correction on it. Basically it's a high bit that's set, not a low one. Doesn't seem to be a very important field though as far as I can tell. I think the game might throw away the packet if it's not set to one or two specific values, or if a certain bit or two isn't set, but otherwise it's ignored.

Title: SIGS/WON
Post by: Highlander on March 23, 2007, 09:54:52 PM

I don't have internet at home now, so I can't download anything.

When you wanted to play multiplayer, you clicked the correct buttons, and you connected to WON. A client would then check you had the necessary patches installed. You then chose your Login name, and from there you went into the topmost room (New Terra I think it was called, and all games hosted in the room would only be LoS maps)

The different gaming rooms had different gaming possibilities(Los, LR SR etc)

Title: SIGS/WON
Post by: alice on March 23, 2007, 10:13:27 PM

Okay, my server is going pretty good so far. I haven't gotten as far as the 2nd connection (not including the login one, but the rooms and the like) but the version checking and everything goes well (for a bit). the Message Formatter is working well (although you have to create the string by using a series of concactenated functions that return the DWORD and other data types right..) This will be done by higher level functions soon, and will eventually lead up to there being working 'rooms'. I already have it set up so that it can accept multiple connections. (I havent bothered to write user authentication code yet, but that doesnt matter right now) I may have a decently functioning server by the end of the weekend. (although I'm not so sure about game creation/joining but this is a good starting point)

Always nice to have a little side project x]

Title: SIGS/WON
Post by: Hooman on March 26, 2007, 12:08:26 AM

Well I've been taking a look at the network code over the last few days. I've got a lot of details filled it on the internal data structures used.

I also found a little about how SIGS can pass the list of player network addresses to the client. On the one hand, this means that SIGS can inform the other clients of a player's external address, but there is one slight problem. The client tries to bind to it's own address. Which means the client must be given a valid internal address on it's own network for the bind to succeed. You can potentially cutom tailor the player's list for each client, so rather than a broadcasted mem copy of a global list, you can update just the client's own address when sending to the client. But there is still a problem. SIGS must know the internal address of the clients. It can very easily get the external address by inspecting the From address when a message or connection arrives at the server, but the internal address would have to be specifically sent inside of a packet. I have yet to observe this behavior for SIGS. This means that even if SIGS can solve the external IP address issue created by home routers, the Outpost 2 network code can still creates another problem with binding to internal addresses.

Also, I've come across many other sections of code that seem to call bind for no real good reason. Suffice it to say fixing up the network code is going to be a pain. The ideal situation is to have a single port for all traffic, which is unbound for clients and initially sends data out, and is bound for a server where traffic must come in. Instead Outpost2 seems to use a seperate port, almost always bound, for pretty much all the different components of the protocol, where the data direction is often intially inbound traffic. If any outgoing traffic is sent first, they seem to have a nasty habit of sending the outgoing data on a different port than they expect the incomming data to come back on.

It seems they've done just about everything they possibly could have to complicate our lives. :(

Outpost Universe Forums

Projects & Development => Outpost 2 Programming & Development => Topic started by: Hooman on December 05, 2006, 09:09:50 PM