Re: [Smonline-devs] Windows compilation fixed, a few small changes

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

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.