Line endings...be normalized!
This commit is contained in:
Jason Felds
@@ -1,84 +1,84 @@
|
||||
sm-ssc Code Style Guidelines
|
||||
--------------------------------------------------------------------------------
|
||||
AJ is biased, but prefers to edit text in SciTE and just uses Visual Studio when
|
||||
necessary. "It's really slow!"
|
||||
|
||||
That being said, the sm-ssc code style guidelines are as follows:
|
||||
|
||||
1) Follow the current coding conventions set forth in the source code.
|
||||
This means use tabs. AJ prefers tabs have a width of 4. Visual Studio and web
|
||||
browsers assume tabs to be 8 by default. :/
|
||||
Use of the tab character means you can define however wide you want it to be.
|
||||
|
||||
Use of the space character is allowed for complex alignment. There are many
|
||||
examples of this in the code.
|
||||
|
||||
If it can be done in one line, do so:
|
||||
int xTwenty(int factor){ return factor*20; }
|
||||
|
||||
Otherwise, follow what's in the code, namely...
|
||||
|
||||
for single line ifs :
|
||||
if( somecrap )
|
||||
dosomethingelse();
|
||||
|
||||
for multi-lines:
|
||||
if( anothercrap )
|
||||
{
|
||||
omg();
|
||||
lotsofstuff();
|
||||
}
|
||||
|
||||
Naming conventions seem to be Hungarian (of Apps or System, I do not know).
|
||||
|
||||
2) Remove any unnecessary whitespace. "Unnecessary" whitespace includes tabs
|
||||
at the end of } characters, tabs that lead nowhere, like this one:
|
||||
|
||||
and keep in mind that this can be done with spaces too:
|
||||
|
||||
so watch yourself. Remove 'em all.
|
||||
|
||||
3) When making LOG->Trace()s in code, it's best to include the name of the Class
|
||||
and Function in [], like so:
|
||||
LOG->Info( "[NetworkSyncManager::Listen] Initializing socket..." );
|
||||
You may not always need to do this, but it helps for clarity and sanity.
|
||||
|
||||
4) Comment style. (This is a preferred suggestion. You may choose to do whatever
|
||||
you like, but it is recommended to follow this style when submitting code for
|
||||
inclusion.)
|
||||
// is preferred for one-liners
|
||||
// and also blocks of text where the comment isn't too long.
|
||||
// sometimes you'll find // comments longer than this thrown in there by AJ
|
||||
/* instead of doing this.
|
||||
* when making a new line in a long form comment, start like this line.
|
||||
* and put the end where it fits. */
|
||||
|
||||
/*
|
||||
* doing this (first line blank) is discouraged, but is allowed in certain places.
|
||||
* Copyright notices use this style and should remain doing so; don't clean it up
|
||||
* in that instance. All new copyright notices should follow this style as well,
|
||||
* for consistency's sake.
|
||||
*/
|
||||
|
||||
/* use of long comments for one line is VERY discouraged */
|
||||
// usually, it will will get cleaned up into this style, but there are exceptions:
|
||||
|
||||
// exception #1: function arguments
|
||||
void SomeFunction(size_t /*ACTUAL DATA TYPE*/)
|
||||
// where you need to have it be /* */ or else it'll mess up.
|
||||
|
||||
// exception #2: #defines
|
||||
#define /* you must use long form in defines, */ \
|
||||
// otherwise it won't parse the newline correctly (this will cause an error) \
|
||||
|
||||
// exception #3: .h files
|
||||
/* ScreenTypicalExample - this always shows up like this. It usually is always one line, even when it extends past column 80. This is acceptible; Most people don't write novels here like I just did. */
|
||||
|
||||
// on comment length:
|
||||
/* typically total 80 characters is the preferred width per line, like this one.
|
||||
* Sometimes, you can get away with sentences where a word or phrase hangs over the edge,
|
||||
* especially if you can guess the context without needing to scroll.
|
||||
* Pre-existing comments are usually trimmed to meet the 80-column width if they
|
||||
* go way overboard. */
|
||||
|
||||
sm-ssc Code Style Guidelines
|
||||
--------------------------------------------------------------------------------
|
||||
AJ is biased, but prefers to edit text in SciTE and just uses Visual Studio when
|
||||
necessary. "It's really slow!"
|
||||
|
||||
That being said, the sm-ssc code style guidelines are as follows:
|
||||
|
||||
1) Follow the current coding conventions set forth in the source code.
|
||||
This means use tabs. AJ prefers tabs have a width of 4. Visual Studio and web
|
||||
browsers assume tabs to be 8 by default. :/
|
||||
Use of the tab character means you can define however wide you want it to be.
|
||||
|
||||
Use of the space character is allowed for complex alignment. There are many
|
||||
examples of this in the code.
|
||||
|
||||
If it can be done in one line, do so:
|
||||
int xTwenty(int factor){ return factor*20; }
|
||||
|
||||
Otherwise, follow what's in the code, namely...
|
||||
|
||||
for single line ifs :
|
||||
if( somecrap )
|
||||
dosomethingelse();
|
||||
|
||||
for multi-lines:
|
||||
if( anothercrap )
|
||||
{
|
||||
omg();
|
||||
lotsofstuff();
|
||||
}
|
||||
|
||||
Naming conventions seem to be Hungarian (of Apps or System, I do not know).
|
||||
|
||||
2) Remove any unnecessary whitespace. "Unnecessary" whitespace includes tabs
|
||||
at the end of } characters, tabs that lead nowhere, like this one:
|
||||
|
||||
and keep in mind that this can be done with spaces too:
|
||||
|
||||
so watch yourself. Remove 'em all.
|
||||
|
||||
3) When making LOG->Trace()s in code, it's best to include the name of the Class
|
||||
and Function in [], like so:
|
||||
LOG->Info( "[NetworkSyncManager::Listen] Initializing socket..." );
|
||||
You may not always need to do this, but it helps for clarity and sanity.
|
||||
|
||||
4) Comment style. (This is a preferred suggestion. You may choose to do whatever
|
||||
you like, but it is recommended to follow this style when submitting code for
|
||||
inclusion.)
|
||||
// is preferred for one-liners
|
||||
// and also blocks of text where the comment isn't too long.
|
||||
// sometimes you'll find // comments longer than this thrown in there by AJ
|
||||
/* instead of doing this.
|
||||
* when making a new line in a long form comment, start like this line.
|
||||
* and put the end where it fits. */
|
||||
|
||||
/*
|
||||
* doing this (first line blank) is discouraged, but is allowed in certain places.
|
||||
* Copyright notices use this style and should remain doing so; don't clean it up
|
||||
* in that instance. All new copyright notices should follow this style as well,
|
||||
* for consistency's sake.
|
||||
*/
|
||||
|
||||
/* use of long comments for one line is VERY discouraged */
|
||||
// usually, it will will get cleaned up into this style, but there are exceptions:
|
||||
|
||||
// exception #1: function arguments
|
||||
void SomeFunction(size_t /*ACTUAL DATA TYPE*/)
|
||||
// where you need to have it be /* */ or else it'll mess up.
|
||||
|
||||
// exception #2: #defines
|
||||
#define /* you must use long form in defines, */ \
|
||||
// otherwise it won't parse the newline correctly (this will cause an error) \
|
||||
|
||||
// exception #3: .h files
|
||||
/* ScreenTypicalExample - this always shows up like this. It usually is always one line, even when it extends past column 80. This is acceptible; Most people don't write novels here like I just did. */
|
||||
|
||||
// on comment length:
|
||||
/* typically total 80 characters is the preferred width per line, like this one.
|
||||
* Sometimes, you can get away with sentences where a word or phrase hangs over the edge,
|
||||
* especially if you can guess the context without needing to scroll.
|
||||
* Pre-existing comments are usually trimmed to meet the 80-column width if they
|
||||
* go way overboard. */
|
||||
|
||||
5) There are no other rules (yet).
|
||||
@@ -1,17 +1,17 @@
|
||||
sm-ssc has a few compile flags that are helpful to know, as well as ones
|
||||
inherited from StepMania.
|
||||
================================================================================
|
||||
stepmania:
|
||||
================================================================================
|
||||
WITHOUT_NETWORKING
|
||||
Disables all networking stuff (SMO).
|
||||
================================================================================
|
||||
sm-ssc:
|
||||
================================================================================
|
||||
SSC_FUTURES
|
||||
{todo}
|
||||
--------------------------------------------------------------------------------
|
||||
HAVE_VERSION_INFO
|
||||
If this isn't defined, passing in --version will only show the name of the
|
||||
current sm-ssc version, no build number or date.
|
||||
sm-ssc has a few compile flags that are helpful to know, as well as ones
|
||||
inherited from StepMania.
|
||||
================================================================================
|
||||
stepmania:
|
||||
================================================================================
|
||||
WITHOUT_NETWORKING
|
||||
Disables all networking stuff (SMO).
|
||||
================================================================================
|
||||
sm-ssc:
|
||||
================================================================================
|
||||
SSC_FUTURES
|
||||
{todo}
|
||||
--------------------------------------------------------------------------------
|
||||
HAVE_VERSION_INFO
|
||||
If this isn't defined, passing in --version will only show the name of the
|
||||
current sm-ssc version, no build number or date.
|
||||
Please define HAVE_VERSION_INFO if you can when building sm-ssc.
|
||||
@@ -1,23 +1,23 @@
|
||||
The Golden Rules of sm-ssc Development
|
||||
--------------------------------------------------------------------------------
|
||||
In addition to CodingStyle.txt, this is the doctrine for operation of sm-ssc.
|
||||
|
||||
1) Always remember that the original branch of StepMania exists, and that we need
|
||||
to give back to it in order for sm-ssc to survive.
|
||||
(Literal: Be sure to commit useful changes/fixes to the mainline StepMania branch
|
||||
every so often.)
|
||||
|
||||
2) If you want something done, you should probably work on it yourself. However,
|
||||
SSC members should be willing to help if their area of expertise and the problem
|
||||
domain overlap (life permitting).
|
||||
|
||||
3) Always know your priorities. sm-ssc is important, but it's not life itself.
|
||||
Take breaks every once in a while. Work on other things. Don't get burned out
|
||||
from nonstop sm-ssc development.
|
||||
|
||||
4) Patches should be checked for compatibility/compilability before being
|
||||
accepted and integrated. Common sense, but a golden rule nevertheless.
|
||||
|
||||
5) Anyone who decides to theme for sm-ssc during development is willing to
|
||||
accept that occasionally, changes to the default and/or fallback theme will
|
||||
The Golden Rules of sm-ssc Development
|
||||
--------------------------------------------------------------------------------
|
||||
In addition to CodingStyle.txt, this is the doctrine for operation of sm-ssc.
|
||||
|
||||
1) Always remember that the original branch of StepMania exists, and that we need
|
||||
to give back to it in order for sm-ssc to survive.
|
||||
(Literal: Be sure to commit useful changes/fixes to the mainline StepMania branch
|
||||
every so often.)
|
||||
|
||||
2) If you want something done, you should probably work on it yourself. However,
|
||||
SSC members should be willing to help if their area of expertise and the problem
|
||||
domain overlap (life permitting).
|
||||
|
||||
3) Always know your priorities. sm-ssc is important, but it's not life itself.
|
||||
Take breaks every once in a while. Work on other things. Don't get burned out
|
||||
from nonstop sm-ssc development.
|
||||
|
||||
4) Patches should be checked for compatibility/compilability before being
|
||||
accepted and integrated. Common sense, but a golden rule nevertheless.
|
||||
|
||||
5) Anyone who decides to theme for sm-ssc during development is willing to
|
||||
accept that occasionally, changes to the default and/or fallback theme will
|
||||
break things.
|
||||
+466
-466
@@ -1,466 +1,466 @@
|
||||
|
||||
PRELIMINARY - - - - - - - - 05/03/2004
|
||||
Protocol version 4
|
||||
But 0x04 will be its version for inter-protocol purposes.
|
||||
|
||||
This protocol is only intended to replace current protocol. Because current protocol
|
||||
not expanable
|
||||
|
||||
SMLAN PROTCOL TCP/8765
|
||||
|
||||
Protcol is entirelly packaged in EzSockets Data Packets (use send and receive packet)
|
||||
|
||||
This will prevent any out-of-sync errors with future or past versions.
|
||||
|
||||
The protocol is impervious to fragmented, or bonded TCP packets.
|
||||
|
||||
Basic Representation:
|
||||
|
||||
Octet 0123 4 5
|
||||
+----+-+---//--+
|
||||
|ssss|C|Payload|
|
||||
+----+-+---//--+
|
||||
|
||||
ssss - size of packet, handled by ezsockets (if you're using C++)
|
||||
C - Command.
|
||||
Payload - variable size based on command
|
||||
|
||||
The payload may contain more data than expected, i.e. new protocol version.
|
||||
|
||||
|
||||
In the following protocol, the term size means the size of the chunk of data.
|
||||
If the "size" is "NT" then that means it's a null-terminating string.
|
||||
"MSN" most significant 4 bits (byte/16)
|
||||
"LSN" least significant 4 bits (byte%16)
|
||||
|
||||
|
||||
Note: Primary player is 0x0, secondary player is 0x1
|
||||
|
||||
CLIENT to SERVER protocol:
|
||||
|
||||
000: No Operation
|
||||
Desc: This command will cause server to respond with a no op response.
|
||||
Payload: None
|
||||
Response: Server 001
|
||||
|
||||
001: No Operation Response
|
||||
Desc: This command is used to respond to a no operation.
|
||||
Payload: None
|
||||
Response: None
|
||||
|
||||
002: Hello
|
||||
Desc: This is the first packet from a client to server, stating below
|
||||
information (NOTE: Names are no longer sent in this packet)
|
||||
Payload:
|
||||
Size Description:
|
||||
1 Client protocol version
|
||||
NT Name of build of StepMania
|
||||
Response: Server 002
|
||||
|
||||
|
||||
|
||||
003: Game Start Request
|
||||
Desc: This command is called once after most loading is done, and
|
||||
again immediately before the sound starts.
|
||||
Payload:
|
||||
Size Description
|
||||
MSN Primary player difficulty (feet) (0 for no player)
|
||||
LSN Secondary player difficulty (feet) (0 for no player)
|
||||
MSN Primary player difficulty (0=Beginner, 1=easy, etc.)
|
||||
LSN Second player difficulty (0=Beginner, 1=easy, etc.)
|
||||
MSN Start Position (0 is pre-sync, 1 is for sync)
|
||||
LSN Reserved
|
||||
NT Song Title
|
||||
NT Song Subtitle
|
||||
NT Song Artist
|
||||
NT Course Title (If none exists; make it just a null)
|
||||
NT Song Options (in string-format)
|
||||
NT Primary Player's options (Null if non-existant)
|
||||
NT Secondary Player's Options (Null if non-existant)
|
||||
|
||||
Response: Server 003
|
||||
|
||||
|
||||
004: Game Over Notice
|
||||
Desc: This command is sent when end of game is encounterd
|
||||
Payload: None.
|
||||
Response: None.
|
||||
|
||||
005: Game Status update
|
||||
Desc: Updates game info for each step
|
||||
Payload:
|
||||
Size Description
|
||||
MSN Player #
|
||||
Protocol <= 2
|
||||
LSN StepID
|
||||
1: Miss
|
||||
2: W5
|
||||
3: W4
|
||||
4: W3
|
||||
5: W2
|
||||
6: W1
|
||||
7: LetGo
|
||||
8: Held
|
||||
Protocol >= 3
|
||||
LSN StepID
|
||||
1: HitMine
|
||||
2: AvoidMine
|
||||
3: Miss
|
||||
4: W5
|
||||
5: W4
|
||||
6: W3
|
||||
7: W2
|
||||
8: W1
|
||||
9: LetGo
|
||||
10: Held
|
||||
|
||||
MSN Projected Grade (StepMania enum int)
|
||||
LSN Reserved
|
||||
4 Net-order long containing score.
|
||||
2 Net-order int containing combo.
|
||||
2 Net-order int containing health.
|
||||
2 Net-order # containing offset
|
||||
32767 would be DEAD on the note
|
||||
If the user is hitting late, the # will be higher
|
||||
It if the user is exactly 0.25 seconds off, the
|
||||
number will be different by 500, if 0.5, it will be
|
||||
different by 1000.
|
||||
Response: None.
|
||||
|
||||
006: Style Update (PLEASE NOTE THIS HAS NOTHING TO DO WITH SERVER COMMAND 6)
|
||||
Desc: This is sent when a style is chosen.
|
||||
Size:
|
||||
1 # of enabled players (1 means 1, 2 means 2)
|
||||
1 Player # (0 means 1st, 1 means 2nd)
|
||||
NT Player Name for #
|
||||
(Additional player's and #'s) (enabled players ONLY)
|
||||
|
||||
Response: None
|
||||
|
||||
007: Chat message
|
||||
Desc: The user typed a message for general chat.
|
||||
Size:
|
||||
NT Message
|
||||
|
||||
008: Request Start Game and Tell server existance/non existance of song.
|
||||
Desc: The user selected a song on a Net-enabled selection
|
||||
Size:
|
||||
1 Usage of message
|
||||
0: (in response to server 8) User has specified song
|
||||
1: (in response to server 8) User does NOT have specified song
|
||||
2: User requested a start game on given song
|
||||
NT Song Title (As gotten by GetTranslitMainTitle)
|
||||
NT Song Artist (As Gotten by GetTranslitArtist)
|
||||
NT Song Subtitle (As gotten by GetTranslitSubTitle)
|
||||
|
||||
009: //Reserved
|
||||
|
||||
010: User entered/exited Network Music Selection Screen
|
||||
Size:
|
||||
1
|
||||
0: exited ScreenNetSelectMusic
|
||||
1: entered ScreenNetSelectMusic
|
||||
2: **Not Sent**
|
||||
3: entered options screen
|
||||
4: exited the evaluation screen
|
||||
5: entered evaluation screen
|
||||
6: exited ScreenNetRoom
|
||||
7: entered ScreenNetRoom
|
||||
|
||||
011: User has changed player options
|
||||
Size:
|
||||
NT Player 0's options
|
||||
NT Player 1's options
|
||||
|
||||
|
||||
012: SMOnline Packet. //SPECIAL CASE!!!
|
||||
NOTE: The smonline packet is not defined here.
|
||||
The SMLan packet 12 is a wrapper for the SMOnline packet.
|
||||
This is so that we can have "protection" of sorts when
|
||||
it comes to the coding of SMOnline, so we don't have to
|
||||
use the lower level commands when dealing with SMOnline.
|
||||
Size:
|
||||
1 SMOnline command //This used to say 2, but it looks like 1 in all cases
|
||||
<VARIABLE> SMOnline data
|
||||
|
||||
|
||||
013: Reserved
|
||||
|
||||
014: Reserved
|
||||
|
||||
015: XML Packet. This packet contains data in XML format.
|
||||
Size:
|
||||
NT XML
|
||||
|
||||
SERVER to CLIENT protocol: (begins at 128)
|
||||
|
||||
NOTE: Server responses always add 128, thus a server response for no operation
|
||||
is 128, not 000
|
||||
|
||||
000(128):No Operation
|
||||
Desc: This command will cause server to respond with a no op response.
|
||||
Payload: None
|
||||
Response: Server 001
|
||||
|
||||
001(129):No Operation Response
|
||||
Desc: This command is used to respond to a no operation.
|
||||
Payload: None
|
||||
Response: None
|
||||
|
||||
002(130):Server Hello Response
|
||||
Desc: This introduces the server.
|
||||
Payload:
|
||||
Size Description
|
||||
1 Server protocol version //NOTE: if protocol version is 128+, then this
|
||||
server is an SMOnline server
|
||||
NT Server Name
|
||||
4 Random key ( at the moment only used for an alternate login method )
|
||||
|
||||
003(131):Allow Start
|
||||
Desc: This will cause the client to start the game.
|
||||
Payload: None
|
||||
Response: None
|
||||
|
||||
004(132):Game over stats
|
||||
Desc: this packet is send in response to the game over packet
|
||||
it contains information regarding how well each player did.
|
||||
Payload:
|
||||
1 # of players sent in this packet (active players)
|
||||
The way this works is to send every player's info for a given
|
||||
field. Like every player's score will be sent first, then every
|
||||
player's grade.
|
||||
1 First player's player ID
|
||||
<Other player's IDs>
|
||||
4 Score
|
||||
<Other player's scores>
|
||||
1 Grade
|
||||
<Other player's Grades>
|
||||
1 Difficulty (0=beginner, 1=light, etc.)
|
||||
<Other player's difficulties>
|
||||
|
||||
#this next chunk of step types is actually reversed
|
||||
2 miss
|
||||
<Other player's misses>
|
||||
2 boo
|
||||
<Other player's boos>
|
||||
2 good (All players)
|
||||
2 great (All players)
|
||||
2 perfect (All players)
|
||||
2 marvelous (All players)
|
||||
|
||||
2 ok (All players)
|
||||
2 max_combo (All players)
|
||||
NT Player's options
|
||||
<Other player's options>
|
||||
|
||||
|
||||
005:(133)Scoreboard update
|
||||
Desc: This will update the client's scoreboard.
|
||||
Payload:
|
||||
Size
|
||||
1 Which section
|
||||
0: Names
|
||||
1: Combos
|
||||
2: Projected Grades
|
||||
1 # of players to display
|
||||
|
||||
If Names, then:
|
||||
1 Player in first place's index
|
||||
1 Player in second place's index
|
||||
...
|
||||
1 Last player's index
|
||||
If Combos, then:
|
||||
2 First player's combo
|
||||
2 Second Player's combo
|
||||
...
|
||||
2 Last player's combo
|
||||
If Project grades
|
||||
1 Player 1's grade (in the same format used when reporting projected grades)
|
||||
1 Player 2's grade
|
||||
...
|
||||
1 Last player's projected grade
|
||||
|
||||
|
||||
006:(134)System Message (PLEASE NOTE THIS HAS NOTHING TO DO WITH CLIENT COMMAND 6)
|
||||
Desc: Send system message to user
|
||||
Payload:
|
||||
Size Description
|
||||
NT Message
|
||||
|
||||
007:(135)Chat Message
|
||||
Desc: Add a chat message to the chat window on some StepMania screens.
|
||||
Payload:
|
||||
Size Description
|
||||
NT Message
|
||||
|
||||
008:(136)Tell client to start song/ask if client has song
|
||||
Desc: The user selected a song on a Net-enabled selection
|
||||
Size:
|
||||
1 Usage of message
|
||||
0: See if client has song
|
||||
1: See if client has song, if so, scroll to song
|
||||
2: See if client has song, if so, scroll to song, and play that song
|
||||
3: Blindly start song
|
||||
NT Song Title (As gotten by GetTranslitMainTitle)
|
||||
NT Song Artist (As Gotten by GetTranslitArtist)
|
||||
NT Song Subtitle (As gotten by GetTranslitSubTitle)
|
||||
|
||||
009:(137)Update user list
|
||||
Desc: This sends all the users currently connected
|
||||
Size:
|
||||
1 Max # of players
|
||||
1 # of players in this packet
|
||||
1 Player 0's status
|
||||
NT Player 0's name (if there is no player here... make it a null (""))
|
||||
1 Player 1's status
|
||||
NT Player 1's name
|
||||
...
|
||||
1 Last player's status
|
||||
NT Last player's name
|
||||
Status:
|
||||
0 Inative (no info on this user yet)
|
||||
1 Active (you know who it is)
|
||||
2 In Selection Screen
|
||||
3 In Options
|
||||
4 In Evaluation
|
||||
|
||||
010:(138)Force change to Networking select music screen.
|
||||
Size:
|
||||
NT Set Specified gametype
|
||||
NT Set Specified style
|
||||
|
||||
011:(139)Reserved
|
||||
|
||||
|
||||
012:(140)SMOnline Packet. //SPECIAL CASE!!!
|
||||
NOTE: The smonline packet is not defined here.
|
||||
The SMLan packet 12 is a wrapper for the SMOnline packet.
|
||||
This is so that we can have "protection" of sorts when
|
||||
it comes to the coding of SMOnline, so we don't have to
|
||||
use the lower level commands when dealing with SMOnline.
|
||||
Size:
|
||||
1 SMOnline command
|
||||
<VARIABLE> SMOnline data
|
||||
|
||||
|
||||
013:(141)Formatted information packet
|
||||
Desc: Send formatted information regarding the server back to the player.
|
||||
NOTE: The purpose of this function is alternatively to be a broadcast
|
||||
packet. (You can expect it via UDP broadcast)
|
||||
Size:
|
||||
NT Server Name
|
||||
2 Port the server is listening on
|
||||
2 Number of players connected
|
||||
|
||||
014:(142)Attack Client
|
||||
Size:
|
||||
1 Player Number
|
||||
4 Time to Last (in MS)
|
||||
NT Text describing modifiers.
|
||||
|
||||
015:(143) XML reply. Contains XML
|
||||
Size:
|
||||
NT XML
|
||||
|
||||
|
||||
----------------------------------------------------------------
|
||||
Client SMOnline packets:
|
||||
000: Send Login Information
|
||||
Size:
|
||||
1 Player Number
|
||||
1 Encryption text
|
||||
0: MD5 hash
|
||||
1: MD5 ( MD5 hash + salt ) (salt is plain text, base 10 string )
|
||||
NT Username
|
||||
NT Password
|
||||
|
||||
Note: The client is not permitted to use method (1) for authentication
|
||||
if the salt it received from the server is 0
|
||||
|
||||
001: User asks to enter room
|
||||
Size:
|
||||
1 Enter/Exit?
|
||||
0: User wishes to exit room
|
||||
1: User wishes to enter room
|
||||
NT Room Name (Used when entering rooms)
|
||||
NT Password (Empty if password not used)
|
||||
|
||||
002: Create a new Room
|
||||
Size:
|
||||
1 Room Type
|
||||
0: Normal room (has sub rooms)
|
||||
1: Game room (no sub rooms)
|
||||
NT Room Title
|
||||
NT Room Description
|
||||
NT Room Password (blank if no password)
|
||||
|
||||
003: Requests Room Info
|
||||
Size:
|
||||
NT Room Name
|
||||
|
||||
|
||||
Server SMOnline packets:
|
||||
000: Login Response
|
||||
1 Approval Status
|
||||
0: Approved
|
||||
1: Approval Failed
|
||||
NT Login response (plain text)
|
||||
|
||||
001: Room Update (Changing rooms)
|
||||
Size:
|
||||
1 Type of update
|
||||
0: Change Room Title
|
||||
1: Update List of other rooms (or games)
|
||||
|
||||
If Room Title Update:
|
||||
NT Room Title
|
||||
NT Room Description
|
||||
1 Type of room:
|
||||
0: Chat room
|
||||
1: Game room
|
||||
1 Allows creation of sub room.
|
||||
0: Does not allow creation of subrooms
|
||||
1: Allows creation of subrooms
|
||||
|
||||
If Room List Update:
|
||||
1 Number of rooms
|
||||
NT Room1 Title
|
||||
NT Room1 Description
|
||||
NT Room2 Title
|
||||
NT Room2 Description
|
||||
...
|
||||
NT RoomN Title
|
||||
NT RoomN Description
|
||||
|
||||
Room Status appended for reverse compatibility
|
||||
1 Room1 Status
|
||||
0: Normal Room
|
||||
1: Unused
|
||||
2: Room in game
|
||||
3: First stage of song selection has been done
|
||||
4: Second stage of song selection has been done
|
||||
1 Room2 Status
|
||||
...
|
||||
1 RoomN Status
|
||||
|
||||
Room Flags appended for reverse compatibility
|
||||
1 Room1 Flags
|
||||
bit 0: Passworded if true
|
||||
1 Room2 Status
|
||||
...
|
||||
1 RoomN Status
|
||||
|
||||
002: Request general information from server.
|
||||
1 Format for stats
|
||||
0: Normal unformatted stats
|
||||
|
||||
003: Room Info
|
||||
Size:
|
||||
NT Last Song Title
|
||||
NT Last Song Subtitle
|
||||
NT Last Song Artist
|
||||
1 Num Players
|
||||
1 Max Players
|
||||
NT Player1 Name
|
||||
...
|
||||
NT PlayerN Name
|
||||
|
||||
PRELIMINARY - - - - - - - - 05/03/2004
|
||||
Protocol version 4
|
||||
But 0x04 will be its version for inter-protocol purposes.
|
||||
|
||||
This protocol is only intended to replace current protocol. Because current protocol
|
||||
not expanable
|
||||
|
||||
SMLAN PROTCOL TCP/8765
|
||||
|
||||
Protcol is entirelly packaged in EzSockets Data Packets (use send and receive packet)
|
||||
|
||||
This will prevent any out-of-sync errors with future or past versions.
|
||||
|
||||
The protocol is impervious to fragmented, or bonded TCP packets.
|
||||
|
||||
Basic Representation:
|
||||
|
||||
Octet 0123 4 5
|
||||
+----+-+---//--+
|
||||
|ssss|C|Payload|
|
||||
+----+-+---//--+
|
||||
|
||||
ssss - size of packet, handled by ezsockets (if you're using C++)
|
||||
C - Command.
|
||||
Payload - variable size based on command
|
||||
|
||||
The payload may contain more data than expected, i.e. new protocol version.
|
||||
|
||||
|
||||
In the following protocol, the term size means the size of the chunk of data.
|
||||
If the "size" is "NT" then that means it's a null-terminating string.
|
||||
"MSN" most significant 4 bits (byte/16)
|
||||
"LSN" least significant 4 bits (byte%16)
|
||||
|
||||
|
||||
Note: Primary player is 0x0, secondary player is 0x1
|
||||
|
||||
CLIENT to SERVER protocol:
|
||||
|
||||
000: No Operation
|
||||
Desc: This command will cause server to respond with a no op response.
|
||||
Payload: None
|
||||
Response: Server 001
|
||||
|
||||
001: No Operation Response
|
||||
Desc: This command is used to respond to a no operation.
|
||||
Payload: None
|
||||
Response: None
|
||||
|
||||
002: Hello
|
||||
Desc: This is the first packet from a client to server, stating below
|
||||
information (NOTE: Names are no longer sent in this packet)
|
||||
Payload:
|
||||
Size Description:
|
||||
1 Client protocol version
|
||||
NT Name of build of StepMania
|
||||
Response: Server 002
|
||||
|
||||
|
||||
|
||||
003: Game Start Request
|
||||
Desc: This command is called once after most loading is done, and
|
||||
again immediately before the sound starts.
|
||||
Payload:
|
||||
Size Description
|
||||
MSN Primary player difficulty (feet) (0 for no player)
|
||||
LSN Secondary player difficulty (feet) (0 for no player)
|
||||
MSN Primary player difficulty (0=Beginner, 1=easy, etc.)
|
||||
LSN Second player difficulty (0=Beginner, 1=easy, etc.)
|
||||
MSN Start Position (0 is pre-sync, 1 is for sync)
|
||||
LSN Reserved
|
||||
NT Song Title
|
||||
NT Song Subtitle
|
||||
NT Song Artist
|
||||
NT Course Title (If none exists; make it just a null)
|
||||
NT Song Options (in string-format)
|
||||
NT Primary Player's options (Null if non-existant)
|
||||
NT Secondary Player's Options (Null if non-existant)
|
||||
|
||||
Response: Server 003
|
||||
|
||||
|
||||
004: Game Over Notice
|
||||
Desc: This command is sent when end of game is encounterd
|
||||
Payload: None.
|
||||
Response: None.
|
||||
|
||||
005: Game Status update
|
||||
Desc: Updates game info for each step
|
||||
Payload:
|
||||
Size Description
|
||||
MSN Player #
|
||||
Protocol <= 2
|
||||
LSN StepID
|
||||
1: Miss
|
||||
2: W5
|
||||
3: W4
|
||||
4: W3
|
||||
5: W2
|
||||
6: W1
|
||||
7: LetGo
|
||||
8: Held
|
||||
Protocol >= 3
|
||||
LSN StepID
|
||||
1: HitMine
|
||||
2: AvoidMine
|
||||
3: Miss
|
||||
4: W5
|
||||
5: W4
|
||||
6: W3
|
||||
7: W2
|
||||
8: W1
|
||||
9: LetGo
|
||||
10: Held
|
||||
|
||||
MSN Projected Grade (StepMania enum int)
|
||||
LSN Reserved
|
||||
4 Net-order long containing score.
|
||||
2 Net-order int containing combo.
|
||||
2 Net-order int containing health.
|
||||
2 Net-order # containing offset
|
||||
32767 would be DEAD on the note
|
||||
If the user is hitting late, the # will be higher
|
||||
It if the user is exactly 0.25 seconds off, the
|
||||
number will be different by 500, if 0.5, it will be
|
||||
different by 1000.
|
||||
Response: None.
|
||||
|
||||
006: Style Update (PLEASE NOTE THIS HAS NOTHING TO DO WITH SERVER COMMAND 6)
|
||||
Desc: This is sent when a style is chosen.
|
||||
Size:
|
||||
1 # of enabled players (1 means 1, 2 means 2)
|
||||
1 Player # (0 means 1st, 1 means 2nd)
|
||||
NT Player Name for #
|
||||
(Additional player's and #'s) (enabled players ONLY)
|
||||
|
||||
Response: None
|
||||
|
||||
007: Chat message
|
||||
Desc: The user typed a message for general chat.
|
||||
Size:
|
||||
NT Message
|
||||
|
||||
008: Request Start Game and Tell server existance/non existance of song.
|
||||
Desc: The user selected a song on a Net-enabled selection
|
||||
Size:
|
||||
1 Usage of message
|
||||
0: (in response to server 8) User has specified song
|
||||
1: (in response to server 8) User does NOT have specified song
|
||||
2: User requested a start game on given song
|
||||
NT Song Title (As gotten by GetTranslitMainTitle)
|
||||
NT Song Artist (As Gotten by GetTranslitArtist)
|
||||
NT Song Subtitle (As gotten by GetTranslitSubTitle)
|
||||
|
||||
009: //Reserved
|
||||
|
||||
010: User entered/exited Network Music Selection Screen
|
||||
Size:
|
||||
1
|
||||
0: exited ScreenNetSelectMusic
|
||||
1: entered ScreenNetSelectMusic
|
||||
2: **Not Sent**
|
||||
3: entered options screen
|
||||
4: exited the evaluation screen
|
||||
5: entered evaluation screen
|
||||
6: exited ScreenNetRoom
|
||||
7: entered ScreenNetRoom
|
||||
|
||||
011: User has changed player options
|
||||
Size:
|
||||
NT Player 0's options
|
||||
NT Player 1's options
|
||||
|
||||
|
||||
012: SMOnline Packet. //SPECIAL CASE!!!
|
||||
NOTE: The smonline packet is not defined here.
|
||||
The SMLan packet 12 is a wrapper for the SMOnline packet.
|
||||
This is so that we can have "protection" of sorts when
|
||||
it comes to the coding of SMOnline, so we don't have to
|
||||
use the lower level commands when dealing with SMOnline.
|
||||
Size:
|
||||
1 SMOnline command //This used to say 2, but it looks like 1 in all cases
|
||||
<VARIABLE> SMOnline data
|
||||
|
||||
|
||||
013: Reserved
|
||||
|
||||
014: Reserved
|
||||
|
||||
015: XML Packet. This packet contains data in XML format.
|
||||
Size:
|
||||
NT XML
|
||||
|
||||
SERVER to CLIENT protocol: (begins at 128)
|
||||
|
||||
NOTE: Server responses always add 128, thus a server response for no operation
|
||||
is 128, not 000
|
||||
|
||||
000(128):No Operation
|
||||
Desc: This command will cause server to respond with a no op response.
|
||||
Payload: None
|
||||
Response: Server 001
|
||||
|
||||
001(129):No Operation Response
|
||||
Desc: This command is used to respond to a no operation.
|
||||
Payload: None
|
||||
Response: None
|
||||
|
||||
002(130):Server Hello Response
|
||||
Desc: This introduces the server.
|
||||
Payload:
|
||||
Size Description
|
||||
1 Server protocol version //NOTE: if protocol version is 128+, then this
|
||||
server is an SMOnline server
|
||||
NT Server Name
|
||||
4 Random key ( at the moment only used for an alternate login method )
|
||||
|
||||
003(131):Allow Start
|
||||
Desc: This will cause the client to start the game.
|
||||
Payload: None
|
||||
Response: None
|
||||
|
||||
004(132):Game over stats
|
||||
Desc: this packet is send in response to the game over packet
|
||||
it contains information regarding how well each player did.
|
||||
Payload:
|
||||
1 # of players sent in this packet (active players)
|
||||
The way this works is to send every player's info for a given
|
||||
field. Like every player's score will be sent first, then every
|
||||
player's grade.
|
||||
1 First player's player ID
|
||||
<Other player's IDs>
|
||||
4 Score
|
||||
<Other player's scores>
|
||||
1 Grade
|
||||
<Other player's Grades>
|
||||
1 Difficulty (0=beginner, 1=light, etc.)
|
||||
<Other player's difficulties>
|
||||
|
||||
#this next chunk of step types is actually reversed
|
||||
2 miss
|
||||
<Other player's misses>
|
||||
2 boo
|
||||
<Other player's boos>
|
||||
2 good (All players)
|
||||
2 great (All players)
|
||||
2 perfect (All players)
|
||||
2 marvelous (All players)
|
||||
|
||||
2 ok (All players)
|
||||
2 max_combo (All players)
|
||||
NT Player's options
|
||||
<Other player's options>
|
||||
|
||||
|
||||
005:(133)Scoreboard update
|
||||
Desc: This will update the client's scoreboard.
|
||||
Payload:
|
||||
Size
|
||||
1 Which section
|
||||
0: Names
|
||||
1: Combos
|
||||
2: Projected Grades
|
||||
1 # of players to display
|
||||
|
||||
If Names, then:
|
||||
1 Player in first place's index
|
||||
1 Player in second place's index
|
||||
...
|
||||
1 Last player's index
|
||||
If Combos, then:
|
||||
2 First player's combo
|
||||
2 Second Player's combo
|
||||
...
|
||||
2 Last player's combo
|
||||
If Project grades
|
||||
1 Player 1's grade (in the same format used when reporting projected grades)
|
||||
1 Player 2's grade
|
||||
...
|
||||
1 Last player's projected grade
|
||||
|
||||
|
||||
006:(134)System Message (PLEASE NOTE THIS HAS NOTHING TO DO WITH CLIENT COMMAND 6)
|
||||
Desc: Send system message to user
|
||||
Payload:
|
||||
Size Description
|
||||
NT Message
|
||||
|
||||
007:(135)Chat Message
|
||||
Desc: Add a chat message to the chat window on some StepMania screens.
|
||||
Payload:
|
||||
Size Description
|
||||
NT Message
|
||||
|
||||
008:(136)Tell client to start song/ask if client has song
|
||||
Desc: The user selected a song on a Net-enabled selection
|
||||
Size:
|
||||
1 Usage of message
|
||||
0: See if client has song
|
||||
1: See if client has song, if so, scroll to song
|
||||
2: See if client has song, if so, scroll to song, and play that song
|
||||
3: Blindly start song
|
||||
NT Song Title (As gotten by GetTranslitMainTitle)
|
||||
NT Song Artist (As Gotten by GetTranslitArtist)
|
||||
NT Song Subtitle (As gotten by GetTranslitSubTitle)
|
||||
|
||||
009:(137)Update user list
|
||||
Desc: This sends all the users currently connected
|
||||
Size:
|
||||
1 Max # of players
|
||||
1 # of players in this packet
|
||||
1 Player 0's status
|
||||
NT Player 0's name (if there is no player here... make it a null (""))
|
||||
1 Player 1's status
|
||||
NT Player 1's name
|
||||
...
|
||||
1 Last player's status
|
||||
NT Last player's name
|
||||
Status:
|
||||
0 Inative (no info on this user yet)
|
||||
1 Active (you know who it is)
|
||||
2 In Selection Screen
|
||||
3 In Options
|
||||
4 In Evaluation
|
||||
|
||||
010:(138)Force change to Networking select music screen.
|
||||
Size:
|
||||
NT Set Specified gametype
|
||||
NT Set Specified style
|
||||
|
||||
011:(139)Reserved
|
||||
|
||||
|
||||
012:(140)SMOnline Packet. //SPECIAL CASE!!!
|
||||
NOTE: The smonline packet is not defined here.
|
||||
The SMLan packet 12 is a wrapper for the SMOnline packet.
|
||||
This is so that we can have "protection" of sorts when
|
||||
it comes to the coding of SMOnline, so we don't have to
|
||||
use the lower level commands when dealing with SMOnline.
|
||||
Size:
|
||||
1 SMOnline command
|
||||
<VARIABLE> SMOnline data
|
||||
|
||||
|
||||
013:(141)Formatted information packet
|
||||
Desc: Send formatted information regarding the server back to the player.
|
||||
NOTE: The purpose of this function is alternatively to be a broadcast
|
||||
packet. (You can expect it via UDP broadcast)
|
||||
Size:
|
||||
NT Server Name
|
||||
2 Port the server is listening on
|
||||
2 Number of players connected
|
||||
|
||||
014:(142)Attack Client
|
||||
Size:
|
||||
1 Player Number
|
||||
4 Time to Last (in MS)
|
||||
NT Text describing modifiers.
|
||||
|
||||
015:(143) XML reply. Contains XML
|
||||
Size:
|
||||
NT XML
|
||||
|
||||
|
||||
----------------------------------------------------------------
|
||||
Client SMOnline packets:
|
||||
000: Send Login Information
|
||||
Size:
|
||||
1 Player Number
|
||||
1 Encryption text
|
||||
0: MD5 hash
|
||||
1: MD5 ( MD5 hash + salt ) (salt is plain text, base 10 string )
|
||||
NT Username
|
||||
NT Password
|
||||
|
||||
Note: The client is not permitted to use method (1) for authentication
|
||||
if the salt it received from the server is 0
|
||||
|
||||
001: User asks to enter room
|
||||
Size:
|
||||
1 Enter/Exit?
|
||||
0: User wishes to exit room
|
||||
1: User wishes to enter room
|
||||
NT Room Name (Used when entering rooms)
|
||||
NT Password (Empty if password not used)
|
||||
|
||||
002: Create a new Room
|
||||
Size:
|
||||
1 Room Type
|
||||
0: Normal room (has sub rooms)
|
||||
1: Game room (no sub rooms)
|
||||
NT Room Title
|
||||
NT Room Description
|
||||
NT Room Password (blank if no password)
|
||||
|
||||
003: Requests Room Info
|
||||
Size:
|
||||
NT Room Name
|
||||
|
||||
|
||||
Server SMOnline packets:
|
||||
000: Login Response
|
||||
1 Approval Status
|
||||
0: Approved
|
||||
1: Approval Failed
|
||||
NT Login response (plain text)
|
||||
|
||||
001: Room Update (Changing rooms)
|
||||
Size:
|
||||
1 Type of update
|
||||
0: Change Room Title
|
||||
1: Update List of other rooms (or games)
|
||||
|
||||
If Room Title Update:
|
||||
NT Room Title
|
||||
NT Room Description
|
||||
1 Type of room:
|
||||
0: Chat room
|
||||
1: Game room
|
||||
1 Allows creation of sub room.
|
||||
0: Does not allow creation of subrooms
|
||||
1: Allows creation of subrooms
|
||||
|
||||
If Room List Update:
|
||||
1 Number of rooms
|
||||
NT Room1 Title
|
||||
NT Room1 Description
|
||||
NT Room2 Title
|
||||
NT Room2 Description
|
||||
...
|
||||
NT RoomN Title
|
||||
NT RoomN Description
|
||||
|
||||
Room Status appended for reverse compatibility
|
||||
1 Room1 Status
|
||||
0: Normal Room
|
||||
1: Unused
|
||||
2: Room in game
|
||||
3: First stage of song selection has been done
|
||||
4: Second stage of song selection has been done
|
||||
1 Room2 Status
|
||||
...
|
||||
1 RoomN Status
|
||||
|
||||
Room Flags appended for reverse compatibility
|
||||
1 Room1 Flags
|
||||
bit 0: Passworded if true
|
||||
1 Room2 Status
|
||||
...
|
||||
1 RoomN Status
|
||||
|
||||
002: Request general information from server.
|
||||
1 Format for stats
|
||||
0: Normal unformatted stats
|
||||
|
||||
003: Room Info
|
||||
Size:
|
||||
NT Last Song Title
|
||||
NT Last Song Subtitle
|
||||
NT Last Song Artist
|
||||
1 Num Players
|
||||
1 Max Players
|
||||
NT Player1 Name
|
||||
...
|
||||
NT PlayerN Name
|
||||
|
||||
+553
-553
File diff suppressed because it is too large
Load Diff
+33
-33
@@ -1,34 +1,34 @@
|
||||
SMXML Control Format | Informal and Unofficial Specification
|
||||
____________________________________________________________
|
||||
There is no formal DTD for SMXML as of this writing, so we can only go on the
|
||||
example file and comments written about the format from developers.
|
||||
|
||||
Chris Danford writes[1]:
|
||||
"I've been finishing a new in-game download system. The goal is to:
|
||||
- Have as few user clicks as possible to install a package (or many packages)
|
||||
- Have one cross-platform method of installing packages
|
||||
|
||||
The new file association - .smxml - contains control data that StepMania will use
|
||||
on launch. The file format currently supports one or more packages to install."
|
||||
|
||||
The canonical sample SMXML file[2] looks like this:
|
||||
<SMXML>
|
||||
<Credentials>
|
||||
<Username>chrisdanford</Username>
|
||||
<PasswordToken>#&DJASDJ#$&$JSD</PasswordToken>
|
||||
</Credentials>
|
||||
<Install>
|
||||
<URL>http://stepmaniam3.com/sm/data/files/Songs_DJMcFox_PlagueMixOne.smzip</URL>
|
||||
</Install>
|
||||
<Install>
|
||||
<URL>http://stepmaniam3.com/sm/data/files/Songs_DJMcFox_PlagueMixTwo.smzip</URL>
|
||||
</Install>
|
||||
</SMXML>
|
||||
|
||||
The Credentials section seems to be optional, but is useful to know about:
|
||||
"In the future, it might also be used to pass login credentials or other tokens
|
||||
from the web site to StepMania for things like in-game uploads (instead of going
|
||||
to stepmaniashare.com)"[1]
|
||||
__________________________________________________________
|
||||
[1] http://www.stepmania.com/forums/showthread.php?t=24203
|
||||
SMXML Control Format | Informal and Unofficial Specification
|
||||
____________________________________________________________
|
||||
There is no formal DTD for SMXML as of this writing, so we can only go on the
|
||||
example file and comments written about the format from developers.
|
||||
|
||||
Chris Danford writes[1]:
|
||||
"I've been finishing a new in-game download system. The goal is to:
|
||||
- Have as few user clicks as possible to install a package (or many packages)
|
||||
- Have one cross-platform method of installing packages
|
||||
|
||||
The new file association - .smxml - contains control data that StepMania will use
|
||||
on launch. The file format currently supports one or more packages to install."
|
||||
|
||||
The canonical sample SMXML file[2] looks like this:
|
||||
<SMXML>
|
||||
<Credentials>
|
||||
<Username>chrisdanford</Username>
|
||||
<PasswordToken>#&DJASDJ#$&$JSD</PasswordToken>
|
||||
</Credentials>
|
||||
<Install>
|
||||
<URL>http://stepmaniam3.com/sm/data/files/Songs_DJMcFox_PlagueMixOne.smzip</URL>
|
||||
</Install>
|
||||
<Install>
|
||||
<URL>http://stepmaniam3.com/sm/data/files/Songs_DJMcFox_PlagueMixTwo.smzip</URL>
|
||||
</Install>
|
||||
</SMXML>
|
||||
|
||||
The Credentials section seems to be optional, but is useful to know about:
|
||||
"In the future, it might also be used to pass login credentials or other tokens
|
||||
from the web site to StepMania for things like in-game uploads (instead of going
|
||||
to stepmaniashare.com)"[1]
|
||||
__________________________________________________________
|
||||
[1] http://www.stepmania.com/forums/showthread.php?t=24203
|
||||
[2] http://www.stepmania.com/test.smxml
|
||||
+13
-13
@@ -1,14 +1,14 @@
|
||||
Code that uses ScreenTextEntry::TextEntry()
|
||||
-------------------------------------------
|
||||
RoomWheel.cpp
|
||||
ScreenEdit.cpp
|
||||
ScreenEditMenu.cpp
|
||||
ScreenNetRoom.cpp
|
||||
ScreenNetworkOptions.cpp
|
||||
ScreenOptionsCourseOverview.cpp
|
||||
ScreenOptionsManageCourses.cpp
|
||||
ScreenOptionsManageEditSteps.cpp
|
||||
ScreenOptionsManageProfiles.cpp
|
||||
ScreenOptionsReviewWorkout.cpp
|
||||
ScreenPackages.cpp
|
||||
Code that uses ScreenTextEntry::TextEntry()
|
||||
-------------------------------------------
|
||||
RoomWheel.cpp
|
||||
ScreenEdit.cpp
|
||||
ScreenEditMenu.cpp
|
||||
ScreenNetRoom.cpp
|
||||
ScreenNetworkOptions.cpp
|
||||
ScreenOptionsCourseOverview.cpp
|
||||
ScreenOptionsManageCourses.cpp
|
||||
ScreenOptionsManageEditSteps.cpp
|
||||
ScreenOptionsManageProfiles.cpp
|
||||
ScreenOptionsReviewWorkout.cpp
|
||||
ScreenPackages.cpp
|
||||
ScreenTestFonts.cpp
|
||||
+16
-16
@@ -1,17 +1,17 @@
|
||||
warps are purple in the editor btw
|
||||
|
||||
beat 445.500 = 107.02325 seconds
|
||||
----------------------------------
|
||||
beat 453.72919 = 107.04103 seconds
|
||||
|
||||
|
||||
00:03.145: ==NotesLoSM negbpm==
|
||||
00:03.145: fnextposbeat = 449.500000, fnextposbpm = 47.419998,
|
||||
00:03.145: fdelta = 4.040333, fwarpto = 453.540344
|
||||
|
||||
00:47.228: ==TimingData Delta as NoteRows==
|
||||
00:47.228: fDeltaBeat = 4.000000 (beat)
|
||||
00:47.228: fDeltaBeat = (NextBPMSeg 0.790333 - abs(fBPS 0.750000)) + (nextStartRow 21576 - thisRow 21384)
|
||||
00:47.228: ==TimingData Delta as Beats==
|
||||
00:47.228: fDeltaBeat = 4.000000 (beat)
|
||||
warps are purple in the editor btw
|
||||
|
||||
beat 445.500 = 107.02325 seconds
|
||||
----------------------------------
|
||||
beat 453.72919 = 107.04103 seconds
|
||||
|
||||
|
||||
00:03.145: ==NotesLoSM negbpm==
|
||||
00:03.145: fnextposbeat = 449.500000, fnextposbpm = 47.419998,
|
||||
00:03.145: fdelta = 4.040333, fwarpto = 453.540344
|
||||
|
||||
00:47.228: ==TimingData Delta as NoteRows==
|
||||
00:47.228: fDeltaBeat = 4.000000 (beat)
|
||||
00:47.228: fDeltaBeat = (NextBPMSeg 0.790333 - abs(fBPS 0.750000)) + (nextStartRow 21576 - thisRow 21384)
|
||||
00:47.228: ==TimingData Delta as Beats==
|
||||
00:47.228: fDeltaBeat = 4.000000 (beat)
|
||||
00:47.228: fDeltaBeat = (NextBPMSeg 0.790333 - abs(fBPS 0.750000)) + (nextStartRow 21576 - thisRow 21384)
|
||||
+131
-131
@@ -1,132 +1,132 @@
|
||||
HOW 2 UZE EZSOKETS BY FWEEM INC
|
||||
|
||||
Hey there. ezsockets is the socket library used in StepMania. If you are going to
|
||||
develop any extended network functionality, it would be good to know about
|
||||
ezsockets. This is by no means an exhaustive guide, as it just covers what's
|
||||
contained in the header, as well as what that code does.
|
||||
|
||||
Section 1: low level commands===================================================
|
||||
These are typically used for connecting to the server, according to a cursory
|
||||
glance at ScreenPackages code.
|
||||
|
||||
=="Crating" a socket== (lol typos in the comments)
|
||||
There are three functions here, each with different arguments (yay overloading).
|
||||
All of them return a bool.
|
||||
|
||||
bool create(int Protocol, int Type);
|
||||
This shows what's needed to make a socket. Consult the internet for complete
|
||||
documentation as to possible values, but here are some ones to know:
|
||||
|
||||
[Protocol]
|
||||
TCP = IPPROTO_TCP
|
||||
UDP = IPPROTO_UDP
|
||||
Raw sockets = IPPROTO_RAW (though "Protocol" is used in the code. Raw sockets
|
||||
are not supported on Xbox)
|
||||
|
||||
bool create();
|
||||
Creates a socket using (IPPROTO_TCP, SOCK_STREAM) as the parameters.
|
||||
|
||||
bool create(int Protocol);
|
||||
This picks the right Type for you based on what Protocol you choose.
|
||||
TCP uses SOCK_STREAM, UDP uses SOCK_DGRAM for the Type value.
|
||||
|
||||
==Binding Sockets to a Local Port==
|
||||
bool bind(unsigned short port);
|
||||
|
||||
==Listening==
|
||||
bool listen()
|
||||
|
||||
==Accepting==
|
||||
bool accept(EzSockets &socket);
|
||||
If it's not blocking and you can't read it, this will return false.
|
||||
Other than that... ??
|
||||
|
||||
==Connecting to Server==
|
||||
bool connect(const string& host, unsigned short port);
|
||||
Connects to the server at host using port.
|
||||
|
||||
==Closing/Killing Sockets==
|
||||
void close();
|
||||
Sets the state to disconnected, sets the buffers to empty strings,
|
||||
then closes the socket.
|
||||
|
||||
==Checking Socket Status==
|
||||
bool check();
|
||||
"see if socket has been created". It checks (sock != INVALID_SOCKET) on the
|
||||
Xbox and (sock > SOCKET_NONE) on every other platform.
|
||||
|
||||
bool CanRead();
|
||||
Returns true if you can read from the socket.
|
||||
|
||||
bool DataAvailable() { return ( ( inBuffer.length()>0 ) || CanRead() ); }
|
||||
Yeah that's it in a nutshell. If the input buffer has data or you can read,
|
||||
there's data available.
|
||||
|
||||
bool IsError();
|
||||
Returns true if there's an error.
|
||||
|
||||
bool CanWrite();
|
||||
Returns true if you can write to the socket.
|
||||
|
||||
==???==
|
||||
long uAddr();
|
||||
void update();
|
||||
|
||||
Section 2: Higher Level Commands================================================
|
||||
These are higher level, since they assume you've already gotten the socket up
|
||||
and running (see check() in Section 1).
|
||||
|
||||
//Raw data system
|
||||
void SendData(const string& outData);
|
||||
void SendData(const char *data, unsigned int bytes);
|
||||
Send off some data that's either a string or a char buffer + num bytes.
|
||||
|
||||
int ReadData(char *data, unsigned int bytes);
|
||||
Reads data, returns number of bytes read.
|
||||
|
||||
int PeekData(char *data, unsigned int bytes);
|
||||
Peeks at the data, returns number of bytes read.
|
||||
|
||||
//Packet system (for structures and classes)
|
||||
void SendPack(const char *data, unsigned int bytes);
|
||||
int ReadPack(char *data, unsigned int max);
|
||||
int PeekPack(char *data, unsigned int max);
|
||||
Similar to the raw data system above, but... you guessed it, for structures and classes.
|
||||
|
||||
//String (Flash) system / Null-terminated strings
|
||||
void SendStr(const string& data, char delim = '\0');
|
||||
int ReadStr(string& data, char delim = '\0');
|
||||
int PeekStr(string& data, char delim = '\0');
|
||||
Similar to above, with null terminated strings.
|
||||
|
||||
Section 3: putting it all together==============================================
|
||||
okay i didn't test this; this is based on ScreenPackages code (specifically
|
||||
ScreenPackages::EnterURL()), which assumes you have a private EzSockets object
|
||||
named m_wSocket.
|
||||
|
||||
{
|
||||
// defaults
|
||||
RString sProto;
|
||||
RString sServer;
|
||||
int iPort=80;
|
||||
RString sAddress;
|
||||
|
||||
m_wSocket.create(); // will create a TCP socket
|
||||
m_wSocket.blocking = true; // you want to set this so that nothing else can use this socket and fuck things up
|
||||
m_wSocket.connect( sServer, (short)iPort ); // connect uses an unsigned short, so a cast is needed. (int was used because of other code) check if this returns true/false, pls
|
||||
|
||||
// makin' headers (using SendData with raw data; http 1.0 in this case)
|
||||
RString Header="";
|
||||
|
||||
Header = "GET "+sAddress+" HTTP/1.0\r\n";
|
||||
Header+= "Host: " + Server + "\r\n";
|
||||
Header+= "Connection: closed\r\n\r\n";
|
||||
|
||||
m_wSocket.SendData( Header.c_str(), Header.length() );
|
||||
|
||||
m_wSocket.blocking = false; // once you're done, you don't need to have the socket blocking anymore
|
||||
|
||||
// some other code can go here...
|
||||
|
||||
m_wSocket.close(); // and if you're done, you can close the socket.
|
||||
HOW 2 UZE EZSOKETS BY FWEEM INC
|
||||
|
||||
Hey there. ezsockets is the socket library used in StepMania. If you are going to
|
||||
develop any extended network functionality, it would be good to know about
|
||||
ezsockets. This is by no means an exhaustive guide, as it just covers what's
|
||||
contained in the header, as well as what that code does.
|
||||
|
||||
Section 1: low level commands===================================================
|
||||
These are typically used for connecting to the server, according to a cursory
|
||||
glance at ScreenPackages code.
|
||||
|
||||
=="Crating" a socket== (lol typos in the comments)
|
||||
There are three functions here, each with different arguments (yay overloading).
|
||||
All of them return a bool.
|
||||
|
||||
bool create(int Protocol, int Type);
|
||||
This shows what's needed to make a socket. Consult the internet for complete
|
||||
documentation as to possible values, but here are some ones to know:
|
||||
|
||||
[Protocol]
|
||||
TCP = IPPROTO_TCP
|
||||
UDP = IPPROTO_UDP
|
||||
Raw sockets = IPPROTO_RAW (though "Protocol" is used in the code. Raw sockets
|
||||
are not supported on Xbox)
|
||||
|
||||
bool create();
|
||||
Creates a socket using (IPPROTO_TCP, SOCK_STREAM) as the parameters.
|
||||
|
||||
bool create(int Protocol);
|
||||
This picks the right Type for you based on what Protocol you choose.
|
||||
TCP uses SOCK_STREAM, UDP uses SOCK_DGRAM for the Type value.
|
||||
|
||||
==Binding Sockets to a Local Port==
|
||||
bool bind(unsigned short port);
|
||||
|
||||
==Listening==
|
||||
bool listen()
|
||||
|
||||
==Accepting==
|
||||
bool accept(EzSockets &socket);
|
||||
If it's not blocking and you can't read it, this will return false.
|
||||
Other than that... ??
|
||||
|
||||
==Connecting to Server==
|
||||
bool connect(const string& host, unsigned short port);
|
||||
Connects to the server at host using port.
|
||||
|
||||
==Closing/Killing Sockets==
|
||||
void close();
|
||||
Sets the state to disconnected, sets the buffers to empty strings,
|
||||
then closes the socket.
|
||||
|
||||
==Checking Socket Status==
|
||||
bool check();
|
||||
"see if socket has been created". It checks (sock != INVALID_SOCKET) on the
|
||||
Xbox and (sock > SOCKET_NONE) on every other platform.
|
||||
|
||||
bool CanRead();
|
||||
Returns true if you can read from the socket.
|
||||
|
||||
bool DataAvailable() { return ( ( inBuffer.length()>0 ) || CanRead() ); }
|
||||
Yeah that's it in a nutshell. If the input buffer has data or you can read,
|
||||
there's data available.
|
||||
|
||||
bool IsError();
|
||||
Returns true if there's an error.
|
||||
|
||||
bool CanWrite();
|
||||
Returns true if you can write to the socket.
|
||||
|
||||
==???==
|
||||
long uAddr();
|
||||
void update();
|
||||
|
||||
Section 2: Higher Level Commands================================================
|
||||
These are higher level, since they assume you've already gotten the socket up
|
||||
and running (see check() in Section 1).
|
||||
|
||||
//Raw data system
|
||||
void SendData(const string& outData);
|
||||
void SendData(const char *data, unsigned int bytes);
|
||||
Send off some data that's either a string or a char buffer + num bytes.
|
||||
|
||||
int ReadData(char *data, unsigned int bytes);
|
||||
Reads data, returns number of bytes read.
|
||||
|
||||
int PeekData(char *data, unsigned int bytes);
|
||||
Peeks at the data, returns number of bytes read.
|
||||
|
||||
//Packet system (for structures and classes)
|
||||
void SendPack(const char *data, unsigned int bytes);
|
||||
int ReadPack(char *data, unsigned int max);
|
||||
int PeekPack(char *data, unsigned int max);
|
||||
Similar to the raw data system above, but... you guessed it, for structures and classes.
|
||||
|
||||
//String (Flash) system / Null-terminated strings
|
||||
void SendStr(const string& data, char delim = '\0');
|
||||
int ReadStr(string& data, char delim = '\0');
|
||||
int PeekStr(string& data, char delim = '\0');
|
||||
Similar to above, with null terminated strings.
|
||||
|
||||
Section 3: putting it all together==============================================
|
||||
okay i didn't test this; this is based on ScreenPackages code (specifically
|
||||
ScreenPackages::EnterURL()), which assumes you have a private EzSockets object
|
||||
named m_wSocket.
|
||||
|
||||
{
|
||||
// defaults
|
||||
RString sProto;
|
||||
RString sServer;
|
||||
int iPort=80;
|
||||
RString sAddress;
|
||||
|
||||
m_wSocket.create(); // will create a TCP socket
|
||||
m_wSocket.blocking = true; // you want to set this so that nothing else can use this socket and fuck things up
|
||||
m_wSocket.connect( sServer, (short)iPort ); // connect uses an unsigned short, so a cast is needed. (int was used because of other code) check if this returns true/false, pls
|
||||
|
||||
// makin' headers (using SendData with raw data; http 1.0 in this case)
|
||||
RString Header="";
|
||||
|
||||
Header = "GET "+sAddress+" HTTP/1.0\r\n";
|
||||
Header+= "Host: " + Server + "\r\n";
|
||||
Header+= "Connection: closed\r\n\r\n";
|
||||
|
||||
m_wSocket.SendData( Header.c_str(), Header.length() );
|
||||
|
||||
m_wSocket.blocking = false; // once you're done, you don't need to have the socket blocking anymore
|
||||
|
||||
// some other code can go here...
|
||||
|
||||
m_wSocket.close(); // and if you're done, you can close the socket.
|
||||
}
|
||||
@@ -1,26 +1,26 @@
|
||||
Notable StepMania CVS commit logs
|
||||
--------------------------------------------------------------------------------
|
||||
http://sourceforge.net/mailarchive/forum.php?thread_name=E1ICWkp-00073O-Ay%40mail.sourceforge.net&forum_name=stepmania-cvs
|
||||
"Any given step can continue the combo, maintain the combo, break the combo, or
|
||||
outright miss. Those that break the combo aren't misses and shouldn't increase
|
||||
the miss counter but they should break the combo."
|
||||
Yeah right it doesn't seem to do that...
|
||||
--------------------------------------------------------------------------------
|
||||
http://sourceforge.net/mailarchive/message.php?msg_id=E1FWjDl-0000Ob-IY%40mail.sourceforge.net
|
||||
"remove unfinished, crufty multiplayer stuff"
|
||||
+
|
||||
http://sourceforge.net/mailarchive/message.php?msg_id=E1FWjpV-0007eC-2G%40mail.sourceforge.net
|
||||
"remove unfinished multiplayer stuff"
|
||||
|
||||
Some of the multiplayer stuff was later re-assembled but I think some of the
|
||||
pieces are missing.
|
||||
|
||||
http://sourceforge.net/mailarchive/message.php?msg_id=E1HbPRZ-0003kC-8h%40mail.sourceforge.net
|
||||
"We have two ways of only showing songs in roulette: unlocks and "#SELECTABLE".
|
||||
|
||||
I'm not sure if this feature is worth keeping, but there definitely doesn't
|
||||
need to be two ways to do it. Remove #SELECTABLE:ROULETTE."
|
||||
________________________________________________________________________________
|
||||
Viewing old source code:
|
||||
http://stepmania.cvs.sourceforge.net/stepmania/stepmania/src/
|
||||
Notable StepMania CVS commit logs
|
||||
--------------------------------------------------------------------------------
|
||||
http://sourceforge.net/mailarchive/forum.php?thread_name=E1ICWkp-00073O-Ay%40mail.sourceforge.net&forum_name=stepmania-cvs
|
||||
"Any given step can continue the combo, maintain the combo, break the combo, or
|
||||
outright miss. Those that break the combo aren't misses and shouldn't increase
|
||||
the miss counter but they should break the combo."
|
||||
Yeah right it doesn't seem to do that...
|
||||
--------------------------------------------------------------------------------
|
||||
http://sourceforge.net/mailarchive/message.php?msg_id=E1FWjDl-0000Ob-IY%40mail.sourceforge.net
|
||||
"remove unfinished, crufty multiplayer stuff"
|
||||
+
|
||||
http://sourceforge.net/mailarchive/message.php?msg_id=E1FWjpV-0007eC-2G%40mail.sourceforge.net
|
||||
"remove unfinished multiplayer stuff"
|
||||
|
||||
Some of the multiplayer stuff was later re-assembled but I think some of the
|
||||
pieces are missing.
|
||||
|
||||
http://sourceforge.net/mailarchive/message.php?msg_id=E1HbPRZ-0003kC-8h%40mail.sourceforge.net
|
||||
"We have two ways of only showing songs in roulette: unlocks and "#SELECTABLE".
|
||||
|
||||
I'm not sure if this feature is worth keeping, but there definitely doesn't
|
||||
need to be two ways to do it. Remove #SELECTABLE:ROULETTE."
|
||||
________________________________________________________________________________
|
||||
Viewing old source code:
|
||||
http://stepmania.cvs.sourceforge.net/stepmania/stepmania/src/
|
||||
put a filename at the end of it.
|
||||
@@ -1,38 +1,38 @@
|
||||
as found by cppcheck against normal sm4svn source (as of 20090527), so
|
||||
line numbers will be different in sm-ssc for some of these.
|
||||
==================================================================================
|
||||
[.\ActorFrameTexture.h:38]: (all) Memory leak: ActorFrameTexture::m_pRenderTarget
|
||||
|
||||
[.\AdjustSync.h:16]: (all) Memory leak: AdjustSync::s_pTimingDataOriginal
|
||||
|
||||
[.\AutoKeysounds.h:32]: (all) Memory leak: AutoKeysounds::m_pSharedSound
|
||||
|
||||
[.\Font.cpp:748]: (all) Memory leak: pPage
|
||||
|
||||
[.\GameSoundManager.cpp:267]: (all) Memory leak: pSound
|
||||
|
||||
[.\LifeMeterTime.h:40]: (all) Memory leak: LifeMeterTime::m_pStream
|
||||
|
||||
[.\MusicWheelItem.h:55]: (all) Memory leak: MusicWheelItem::m_pTextSectionCount
|
||||
|
||||
[.\OptionRow.h:131]: (all) Memory leak: OptionRow::m_textTitle
|
||||
|
||||
[.\PitchDetectionTestUtil.cpp:928]: (error) Mismatching allocation and deallocation: inarray
|
||||
[.\PitchDetectionTestUtil.cpp:968]: (error) Mismatching allocation and deallocation: a
|
||||
|
||||
[.\RageFile.cpp:377]: (all) Memory leak: pFile
|
||||
|
||||
[.\RageFileDriverDeflate.cpp:533]: (all) Memory leak: mem
|
||||
|
||||
[.\RageSoundReader_ChannelSplit.h:57]: (all) Memory leak: RageSoundSplitter::m_pImpl
|
||||
|
||||
[.\RageSoundReader_PitchChange.h:25]: (all) Memory leak: RageSoundReader_PitchChange::m_pSpeedChange
|
||||
[.\RageSoundReader_PitchChange.h:26]: (all) Memory leak: RageSoundReader_PitchChange::m_pResample
|
||||
|
||||
[.\RageThreads.cpp:141]: (all) Memory leak: pLock
|
||||
|
||||
[.\archutils\Unix\CrashHandlerChild.cpp:290]: (error) Resource leak: tty
|
||||
|
||||
[.\crypto\CryptRSA.cpp:447]: (error) Memory leak: rsa
|
||||
|
||||
as found by cppcheck against normal sm4svn source (as of 20090527), so
|
||||
line numbers will be different in sm-ssc for some of these.
|
||||
==================================================================================
|
||||
[.\ActorFrameTexture.h:38]: (all) Memory leak: ActorFrameTexture::m_pRenderTarget
|
||||
|
||||
[.\AdjustSync.h:16]: (all) Memory leak: AdjustSync::s_pTimingDataOriginal
|
||||
|
||||
[.\AutoKeysounds.h:32]: (all) Memory leak: AutoKeysounds::m_pSharedSound
|
||||
|
||||
[.\Font.cpp:748]: (all) Memory leak: pPage
|
||||
|
||||
[.\GameSoundManager.cpp:267]: (all) Memory leak: pSound
|
||||
|
||||
[.\LifeMeterTime.h:40]: (all) Memory leak: LifeMeterTime::m_pStream
|
||||
|
||||
[.\MusicWheelItem.h:55]: (all) Memory leak: MusicWheelItem::m_pTextSectionCount
|
||||
|
||||
[.\OptionRow.h:131]: (all) Memory leak: OptionRow::m_textTitle
|
||||
|
||||
[.\PitchDetectionTestUtil.cpp:928]: (error) Mismatching allocation and deallocation: inarray
|
||||
[.\PitchDetectionTestUtil.cpp:968]: (error) Mismatching allocation and deallocation: a
|
||||
|
||||
[.\RageFile.cpp:377]: (all) Memory leak: pFile
|
||||
|
||||
[.\RageFileDriverDeflate.cpp:533]: (all) Memory leak: mem
|
||||
|
||||
[.\RageSoundReader_ChannelSplit.h:57]: (all) Memory leak: RageSoundSplitter::m_pImpl
|
||||
|
||||
[.\RageSoundReader_PitchChange.h:25]: (all) Memory leak: RageSoundReader_PitchChange::m_pSpeedChange
|
||||
[.\RageSoundReader_PitchChange.h:26]: (all) Memory leak: RageSoundReader_PitchChange::m_pResample
|
||||
|
||||
[.\RageThreads.cpp:141]: (all) Memory leak: pLock
|
||||
|
||||
[.\archutils\Unix\CrashHandlerChild.cpp:290]: (error) Resource leak: tty
|
||||
|
||||
[.\crypto\CryptRSA.cpp:447]: (error) Memory leak: rsa
|
||||
|
||||
[.\smpackage\ZipArchive\Linux\ZipPlatform.cpp:87]: (style) Found 'mktemp'. You should use 'mkstemp' instead
|
||||
+79
-79
@@ -1,80 +1,80 @@
|
||||
okay what we should probabably do for rival data is fuck up stats somehow.
|
||||
|
||||
Here's what rival data should have, taken from Stats.xml
|
||||
|
||||
==GeneralData==
|
||||
This section holds very BASIC identifying and general information.
|
||||
|
||||
<GeneralData>
|
||||
<DisplayName>AJ</DisplayName>
|
||||
<Guid>5ece7871bd060600</Guid>
|
||||
<LastPlayedMachineGuid>faeae5b0da56509c</LastPlayedMachineGuid>
|
||||
<LastPlayedDate>2008-07-06</LastPlayedDate>
|
||||
</GeneralData>
|
||||
|
||||
==SongScores==
|
||||
Where song scores are held. Each song has its own entry in here.
|
||||
|
||||
<Song Dir='Songs/Dance Dance Revolution 6th Mix -Max-/Do It Right/'>
|
||||
<Steps Difficulty='Hard' StepsType='dance-single'>
|
||||
<HighScoreList>
|
||||
<NumTimesPlayed>2</NumTimesPlayed>
|
||||
<LastPlayed>2008-02-08</LastPlayed>
|
||||
<HighGrade>Tier02</HighGrade>
|
||||
|
||||
<HighScore>
|
||||
<Grade>Tier02</Grade>
|
||||
<PercentDP>0.952000</PercentDP>
|
||||
<Modifiers>3x, Overhead, delta</Modifiers>
|
||||
<DateTime>2008-02-08 17:12:08</DateTime>
|
||||
<PlayerGuid>5ece7871bd060600</PlayerGuid>
|
||||
<MachineGuid>faeae5b0da56509c</MachineGuid>
|
||||
|
||||
<TapNoteScores>
|
||||
<HitMine>0</HitMine>
|
||||
<AvoidMine>0</AvoidMine>
|
||||
<CheckpointMiss>0</CheckpointMiss>
|
||||
<Miss>0</Miss>
|
||||
<W5>0</W5>
|
||||
<W4>0</W4>
|
||||
<W3>0</W3>
|
||||
<W2>41</W2>
|
||||
<W1>244</W1>
|
||||
<CheckpointHit>0</CheckpointHit>
|
||||
</TapNoteScores>
|
||||
|
||||
<HoldNoteScores>
|
||||
<LetGo>0</LetGo>
|
||||
<Held>0</Held>
|
||||
</HoldNoteScores>
|
||||
</HighScore>
|
||||
|
||||
<HighScore>
|
||||
<Grade>Tier03</Grade>
|
||||
<PercentDP>0.942600</PercentDP>
|
||||
<Modifiers>3x, delta</Modifiers>
|
||||
<DateTime>2008-02-08 17:08:17</DateTime>
|
||||
<PlayerGuid>5ece7871bd060600</PlayerGuid>
|
||||
<MachineGuid>faeae5b0da56509c</MachineGuid>
|
||||
|
||||
<TapNoteScores>
|
||||
<HitMine>0</HitMine>
|
||||
<AvoidMine>0</AvoidMine>
|
||||
<CheckpointMiss>0</CheckpointMiss>
|
||||
<Miss>0</Miss>
|
||||
<W5>0</W5>
|
||||
<W4>1</W4>
|
||||
<W3>0</W3>
|
||||
<W2>46</W2>
|
||||
<W1>238</W1>
|
||||
<CheckpointHit>0</CheckpointHit>
|
||||
</TapNoteScores>
|
||||
|
||||
<HoldNoteScores>
|
||||
<LetGo>0</LetGo>
|
||||
<Held>0</Held>
|
||||
</HoldNoteScores>
|
||||
</HighScore>
|
||||
</HighScoreList>
|
||||
</Steps>
|
||||
okay what we should probabably do for rival data is fuck up stats somehow.
|
||||
|
||||
Here's what rival data should have, taken from Stats.xml
|
||||
|
||||
==GeneralData==
|
||||
This section holds very BASIC identifying and general information.
|
||||
|
||||
<GeneralData>
|
||||
<DisplayName>AJ</DisplayName>
|
||||
<Guid>5ece7871bd060600</Guid>
|
||||
<LastPlayedMachineGuid>faeae5b0da56509c</LastPlayedMachineGuid>
|
||||
<LastPlayedDate>2008-07-06</LastPlayedDate>
|
||||
</GeneralData>
|
||||
|
||||
==SongScores==
|
||||
Where song scores are held. Each song has its own entry in here.
|
||||
|
||||
<Song Dir='Songs/Dance Dance Revolution 6th Mix -Max-/Do It Right/'>
|
||||
<Steps Difficulty='Hard' StepsType='dance-single'>
|
||||
<HighScoreList>
|
||||
<NumTimesPlayed>2</NumTimesPlayed>
|
||||
<LastPlayed>2008-02-08</LastPlayed>
|
||||
<HighGrade>Tier02</HighGrade>
|
||||
|
||||
<HighScore>
|
||||
<Grade>Tier02</Grade>
|
||||
<PercentDP>0.952000</PercentDP>
|
||||
<Modifiers>3x, Overhead, delta</Modifiers>
|
||||
<DateTime>2008-02-08 17:12:08</DateTime>
|
||||
<PlayerGuid>5ece7871bd060600</PlayerGuid>
|
||||
<MachineGuid>faeae5b0da56509c</MachineGuid>
|
||||
|
||||
<TapNoteScores>
|
||||
<HitMine>0</HitMine>
|
||||
<AvoidMine>0</AvoidMine>
|
||||
<CheckpointMiss>0</CheckpointMiss>
|
||||
<Miss>0</Miss>
|
||||
<W5>0</W5>
|
||||
<W4>0</W4>
|
||||
<W3>0</W3>
|
||||
<W2>41</W2>
|
||||
<W1>244</W1>
|
||||
<CheckpointHit>0</CheckpointHit>
|
||||
</TapNoteScores>
|
||||
|
||||
<HoldNoteScores>
|
||||
<LetGo>0</LetGo>
|
||||
<Held>0</Held>
|
||||
</HoldNoteScores>
|
||||
</HighScore>
|
||||
|
||||
<HighScore>
|
||||
<Grade>Tier03</Grade>
|
||||
<PercentDP>0.942600</PercentDP>
|
||||
<Modifiers>3x, delta</Modifiers>
|
||||
<DateTime>2008-02-08 17:08:17</DateTime>
|
||||
<PlayerGuid>5ece7871bd060600</PlayerGuid>
|
||||
<MachineGuid>faeae5b0da56509c</MachineGuid>
|
||||
|
||||
<TapNoteScores>
|
||||
<HitMine>0</HitMine>
|
||||
<AvoidMine>0</AvoidMine>
|
||||
<CheckpointMiss>0</CheckpointMiss>
|
||||
<Miss>0</Miss>
|
||||
<W5>0</W5>
|
||||
<W4>1</W4>
|
||||
<W3>0</W3>
|
||||
<W2>46</W2>
|
||||
<W1>238</W1>
|
||||
<CheckpointHit>0</CheckpointHit>
|
||||
</TapNoteScores>
|
||||
|
||||
<HoldNoteScores>
|
||||
<LetGo>0</LetGo>
|
||||
<Held>0</Held>
|
||||
</HoldNoteScores>
|
||||
</HighScore>
|
||||
</HighScoreList>
|
||||
</Steps>
|
||||
</Song>
|
||||
+11
-11
@@ -1,12 +1,12 @@
|
||||
[as taken from src/ProductInfo.h]
|
||||
|
||||
Version info displayed to the user.
|
||||
|
||||
These are the 'official' version designations:
|
||||
* "experimental: pre-release versions
|
||||
* "private beta v0.0": hmm, think about it for a second there.
|
||||
==Public versions below this line==
|
||||
* "v0.0 alpha #": Alpha versions (bug squashing, polishing until we reach beta)
|
||||
* "v0.0 beta #": Beta versions (bug squashing, _focus_ is on high priority bugs)
|
||||
* "v0.0 rc#": Release Candidates (if there are no problems, move on to final)
|
||||
[as taken from src/ProductInfo.h]
|
||||
|
||||
Version info displayed to the user.
|
||||
|
||||
These are the 'official' version designations:
|
||||
* "experimental: pre-release versions
|
||||
* "private beta v0.0": hmm, think about it for a second there.
|
||||
==Public versions below this line==
|
||||
* "v0.0 alpha #": Alpha versions (bug squashing, polishing until we reach beta)
|
||||
* "v0.0 beta #": Beta versions (bug squashing, _focus_ is on high priority bugs)
|
||||
* "v0.0 rc#": Release Candidates (if there are no problems, move on to final)
|
||||
* "v0.0": Final Releases
|
||||
Reference in New Issue
Block a user