|
From: Gregory N. <gre...@gm...> - 2009-07-15 16:01:16
|
On Wed, Jul 15, 2009 at 6:57 AM, Josh <axl...@gm...> wrote: > Gregory Najda wrote: > > Hi, I'm interested in extending the SMO protocol so that songs are > > identified by a hash in addition to title, subtitle, and artist so > > that the correct song gets played by all players even if it's a > > commonly-stepped song and they have more than one stepfile of it. I > > talked with Charles for a bit a couple weeks ago and I learned that > > the SVN code is an incomplete new version. > We considered this originally, but issues will arise if the song's > offset is adjusted. If you can get it to work, great! As AJ pointed out to me, there is a Steps::GetHash() function in the Stepmania code. It returns a hash of the internal representation of a single chart of a stepfile, without taking bpm(s), offset, author, or anything other than the stuff that looks like 0000 2000 0000 3200 in a canonical form into account. Experimentation confirms it. I had originally thought of calculating a song hash by simply adding up the hashes for each of the charts, but someone on the Stepmania forums thought it might be a good idea to allow stepfiles with added, removed, or moved charts to be considered a match. That could be done by sending a list of the hashes for all the charts, and the stepfile that contains the most charts that match the hashes sent is the one to be played. I'm not sure if this would be adding complexity for little benefit. The way I currently have it implemented in my modification to Stepmania is to add a 4-byte song hash field to the end of client packets 3 and 8 (Game Start Request/Request Start Game and Tell server existance/non existance of song) and to look for a 4-byte hash in server packet 8 (Tell client to start song/ask if client has song). If the client sees that the packet contains the field, it uses the hash to select the correct song, if not, it selects the first song it finds with title/subtitle/artist that match like it always has. Since it's just adding a field to the end, it's backward-compatible. Old clients and servers will just harmlessly ignore it, and new clients and servers can check the size of the packet to see if the field is present or not. Or the protocol version number could be changed and that can be used to decide whether or not to expect the field. > > > > - Made a bunch of things that have destructors but that don't define > > copy constructor/copy assignment inherit from boost::noncopyable - to > > prevent copying of objects that shouldn't be copied. > The compiler will make a useable copy constructor, if you don't need a > deep memory copy. Any class that has a non-default destructor will typically either need deep copying behavior or doesn't make sense to copy. |