Re: [Smonline-devs] SM and SMO server patch for better disambiguation

[Gregory N. <gre...@gm...>]

The attachments didn't make it through the mailing list apparently, so you
can download them here:

Stepmania patch:
http://www.cs.stevens.edu/~gnajda/Stepmania/stepmania_online_hashes.patch
SMO Server patch: http://www.cs.stevens.edu/~gnajda/SMO/SMO_hashes.patch

On Thu, Aug 13, 2009 at 8:15 PM, Gregory Najda <gre...@gm...> wrote:

> Attached are patches I've created for Stepmania and the SMO server to solve
> the problem of deciding which stepfile to use when a client has more than
> one stepfile with the same title, subtitle, and artist that the room host
> chooses. It works by room hosts sending a list of chart hashes in addition
> to title/subtitle/artist when selecting a song. The stepfile with the same
> title, subtitle, and artist (case-insensitive) with the most charts that
> match is the one that gets used. If more than one stepfile meets that
> criteria, the one currently selected by song wheel cursor is used if it is
> one of them, otherwise the first stepfile it gets to. If no chart hashes are
> received from the server, the old method of using only title, subtitle, and
> artist (and song wheel cursor) is used.
>
> Packets modified:
> Client Hello - client protocol version changed from 3 to 4.
> Server Hello - server protocol version changed from 128 to 129.
> Client Game Start Request - list of hashes added.
> Client Request Start Game and Tell server existance/non existance of song -
> list of hashes added.
> Server Tell client to start song/ask if client has song - list of hashes
> added.
>
> The "list of hashes" is 4 bytes indicating the size of the list, followed
> by however many 4 byte hashes. The server will send the hashes out in the
> same order it got them, however the order has no meaning. The hash for a
> chart is obtained by calling Steps::GetHash(). As such, it only takes into
> account the "note data", not title, bpm, or anything like that.
>
> I also discovered a feature that was in the old code, and that I have
> preserved: that if you have the song wheel cursor on a song that's as good a
> match as any other song, it will use the currently selected song, where it
> would otherwise use the first song it got to. I had never heard of that; it
> ought to be documented somewhere other than the code.
>
> These changes are completely backwards-compatible. New and old clients can
> interact with new servers and old servers. The benefit is not gained unless
> the server is running the update and the room host is running the updated
> client, but it just behaves like it always has if that is not the case.
>
> Also included in the Stepmania patch is a small change to mutex locking
> when running a debug build. While stepping through code, I would get
> spurious deadlock detections likely due to me thinking for longer than 15
> seconds (the mutex wait timeout) before stepping to the next line, so I
> changed the timeout value in debug builds to be infinite since you can just
> stop the program and examine the cause of a deadlock if you're debugging.
>
> - Greg Najda, aka LordHighCaptain
>