smonline-devs

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

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

I've committed the server changes.

- Greg

On Sat, Aug 15, 2009 at 1:17 PM, Josh <axl...@gm...> wrote:

> I'm ok with it.  I skimmed over the patch quickly, I didn't apply or test
> it.
>
> Josh
>
>
> Chris Danford wrote:
>
>> Thanks very much Greg!
>>
>> I'll be happy to integrate these.  Maybe Charles or Josh could take a
>> quick look to make sure they're OK before I apply them.
>>
>> -Chris
>>
>>
>>
>> On Fri, Aug 14, 2009 at 12:37 PM, Gregory Najda <gre...@gm...<mailto:
>> gre...@gm...>> wrote:
>>
>>    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<http://www.cs.stevens.edu/%7Egnajda/Stepmania/stepmania_online_hashes.patch>
>>    <
>> http://www.cs.stevens.edu/%7Egnajda/Stepmania/stepmania_online_hashes.patch
>> >
>>    SMO Server patch:
>>    http://www.cs.stevens.edu/~gnajda/SMO/SMO_hashes.patch<http://www.cs.stevens.edu/%7Egnajda/SMO/SMO_hashes.patch>
>>    <http://www.cs.stevens.edu/%7Egnajda/SMO/SMO_hashes.patch>
>>
>>    On Thu, Aug 13, 2009 at 8:15 PM, Gregory Najda
>>    <gre...@gm... <mailto: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
>>    >
>>
>>  ------------------------------------------------------------------------------
>>    Let Crystal Reports handle the reporting - Free Crystal Reports
>>    2008 30-Day
>>    trial. Simplify your report design, integration and deployment -
>>    and focus on
>>    what you do best, core application coding. Discover what's new with
>>    Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>>    _______________________________________________
>>    Stepmania-devs mailing list
>>    Ste...@li...
>>    <mailto:Ste...@li...>
>>    https://lists.sourceforge.net/lists/listinfo/stepmania-devs
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>> 30-Day trial. Simplify your report design, integration and deployment - and
>> focus on what you do best, core application coding. Discover what's new with
>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Smonline-devs mailing list
>> Smo...@li...
>> https://lists.sourceforge.net/lists/listinfo/smonline-devs
>>
>>
>
>

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

[Josh <axl...@gm...>]

I'm ok with it.  I skimmed over the patch quickly, I didn't apply or 
test it.

Josh


Chris Danford wrote:
> Thanks very much Greg!
>
> I'll be happy to integrate these.  Maybe Charles or Josh could take a 
> quick look to make sure they're OK before I apply them.
>
> -Chris
>
>
>
> On Fri, Aug 14, 2009 at 12:37 PM, Gregory Najda <gre...@gm... 
> <mailto:gre...@gm...>> wrote:
>
>     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
>     <http://www.cs.stevens.edu/%7Egnajda/Stepmania/stepmania_online_hashes.patch>
>     SMO Server patch:
>     http://www.cs.stevens.edu/~gnajda/SMO/SMO_hashes.patch
>     <http://www.cs.stevens.edu/%7Egnajda/SMO/SMO_hashes.patch>
>
>     On Thu, Aug 13, 2009 at 8:15 PM, Gregory Najda
>     <gre...@gm... <mailto: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
>     >
>     ------------------------------------------------------------------------------
>     Let Crystal Reports handle the reporting - Free Crystal Reports
>     2008 30-Day
>     trial. Simplify your report design, integration and deployment -
>     and focus on
>     what you do best, core application coding. Discover what's new with
>     Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>     _______________________________________________
>     Stepmania-devs mailing list
>     Ste...@li...
>     <mailto:Ste...@li...>
>     https://lists.sourceforge.net/lists/listinfo/stepmania-devs
>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> ------------------------------------------------------------------------
>
> _______________________________________________
> Smonline-devs mailing list
> Smo...@li...
> https://lists.sourceforge.net/lists/listinfo/smonline-devs
>   

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

[Josh <axl...@gm...>]

You have access to it. Check your TortoiseCVS settings.

Josh



Gregory Najda wrote:
> That, and I don't seem to have CVS access, only SVN. Could be that I'm 
> doing something wrong with TortoiseCVS.
>
> On Fri, Aug 14, 2009 at 5:35 PM, Josh <axl...@gm... 
> <mailto:axl...@gm...>> wrote:
>
>     Why not submit it to the repository? At least for SMO.
>     Do you want our opinion on it first?
>
>     Josh
>
>
>     Gregory Najda wrote:
>     > 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
>     <http://www.cs.stevens.edu/%7Egnajda/Stepmania/stepmania_online_hashes.patch>
>     >
>     <http://www.cs.stevens.edu/%7Egnajda/Stepmania/stepmania_online_hashes.patch>
>     > SMO Server patch:
>     > http://www.cs.stevens.edu/~gnajda/SMO/SMO_hashes.patch
>     <http://www.cs.stevens.edu/%7Egnajda/SMO/SMO_hashes.patch>
>     > <http://www.cs.stevens.edu/%7Egnajda/SMO/SMO_hashes.patch>
>     >
>     > On Thu, Aug 13, 2009 at 8:15 PM, Gregory Najda
>     <gre...@gm... <mailto:gre...@gm...>
>     > <mailto:gre...@gm... <mailto: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
>     >
>     >
>     >
>     ------------------------------------------------------------------------
>     >
>     >
>     ------------------------------------------------------------------------------
>     > Let Crystal Reports handle the reporting - Free Crystal Reports
>     2008 30-Day
>     > trial. Simplify your report design, integration and deployment -
>     and focus on
>     > what you do best, core application coding. Discover what's new with
>     > Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>     >
>     ------------------------------------------------------------------------
>     >
>     > _______________________________________________
>     > Smonline-devs mailing list
>     > Smo...@li...
>     <mailto:Smo...@li...>
>     > https://lists.sourceforge.net/lists/listinfo/smonline-devs
>     >
>
>
>     ------------------------------------------------------------------------------
>     Let Crystal Reports handle the reporting - Free Crystal Reports
>     2008 30-Day
>     trial. Simplify your report design, integration and deployment -
>     and focus on
>     what you do best, core application coding. Discover what's new with
>     Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>     _______________________________________________
>     Smonline-devs mailing list
>     Smo...@li...
>     <mailto:Smo...@li...>
>     https://lists.sourceforge.net/lists/listinfo/smonline-devs
>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> ------------------------------------------------------------------------
>
> _______________________________________________
> Smonline-devs mailing list
> Smo...@li...
> https://lists.sourceforge.net/lists/listinfo/smonline-devs
>   

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

[Chris D. <ch...@st...>]

Thanks very much Greg!

I'll be happy to integrate these.  Maybe Charles or Josh could take a quick
look to make sure they're OK before I apply them.

-Chris



On Fri, Aug 14, 2009 at 12:37 PM, Gregory Najda <gre...@gm...> wrote:

> 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<http://www.cs.stevens.edu/%7Egnajda/Stepmania/stepmania_online_hashes.patch>
> SMO Server patch: http://www.cs.stevens.edu/~gnajda/SMO/SMO_hashes.patch<http://www.cs.stevens.edu/%7Egnajda/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
> >
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Stepmania-devs mailing list
> Ste...@li...
> https://lists.sourceforge.net/lists/listinfo/stepmania-devs
>

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

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

That, and I don't seem to have CVS access, only SVN. Could be that I'm doing
something wrong with TortoiseCVS.

On Fri, Aug 14, 2009 at 5:35 PM, Josh <axl...@gm...> wrote:

> Why not submit it to the repository? At least for SMO.
> Do you want our opinion on it first?
>
> Josh
>
>
> Gregory Najda wrote:
> > 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<http://www.cs.stevens.edu/%7Egnajda/Stepmania/stepmania_online_hashes.patch>
> > <
> http://www.cs.stevens.edu/%7Egnajda/Stepmania/stepmania_online_hashes.patch
> >
> > SMO Server patch:
> > http://www.cs.stevens.edu/~gnajda/SMO/SMO_hashes.patch<http://www.cs.stevens.edu/%7Egnajda/SMO/SMO_hashes.patch>
> > <http://www.cs.stevens.edu/%7Egnajda/SMO/SMO_hashes.patch>
> >
> > On Thu, Aug 13, 2009 at 8:15 PM, Gregory Najda <gre...@gm...
> > <mailto: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
> >
> >
> > ------------------------------------------------------------------------
> >
> >
> ------------------------------------------------------------------------------
> > Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day
> > trial. Simplify your report design, integration and deployment - and
> focus on
> > what you do best, core application coding. Discover what's new with
> > Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Smonline-devs mailing list
> > Smo...@li...
> > https://lists.sourceforge.net/lists/listinfo/smonline-devs
> >
>
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Smonline-devs mailing list
> Smo...@li...
> https://lists.sourceforge.net/lists/listinfo/smonline-devs
>

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

[Josh <axl...@gm...>]

Why not submit it to the repository? At least for SMO.
Do you want our opinion on it first?

Josh


Gregory Najda wrote:
> 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 
> <http://www.cs.stevens.edu/%7Egnajda/Stepmania/stepmania_online_hashes.patch>
> SMO Server patch: 
> http://www.cs.stevens.edu/~gnajda/SMO/SMO_hashes.patch 
> <http://www.cs.stevens.edu/%7Egnajda/SMO/SMO_hashes.patch>
>
> On Thu, Aug 13, 2009 at 8:15 PM, Gregory Najda <gre...@gm... 
> <mailto: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
>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> ------------------------------------------------------------------------
>
> _______________________________________________
> Smonline-devs mailing list
> Smo...@li...
> https://lists.sourceforge.net/lists/listinfo/smonline-devs
>   

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
>

Re: [Smonline-devs] Stable version?

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

I'm using Visual C++ 2008. I've found the problem in
SMOnlineRoom::UpdateClients().

do
{
    //As long as we keep getting data from the socket, keep processing it
    length = m_clients[x]->Update(m_packet);
    if (length > 0)
        ParseData(m_packet, x);
    //Check for NULL incase the client switched rooms
} while ((length > 0) && (m_clients[x]));

If the client switched rooms, then m_clients[x] no longer refers to the
client it used to, and in the case of only one client in the vector or the
client being the last element of the vector, x is out-of-bounds. It's not
surprising that it does bounds-checking in a debug build, but apparently it
does it even in the release build.

To fix, I've replaced the loop condition with

} while ((length > 0) && (x < m_clients.size()) && (m_clients[x]));

It appears to work now.

On Mon, Aug 3, 2009 at 1:36 PM, Charles Lohr <ch...@cn...> wrote:

> 1) What compiler are you using for it?
> 2) Uninitialized values changed behavior between VC6 and all .NET
> MSVC's.  Using Valgrind in Linux should be able to point the problem out
> instantly.
> 3) Debugger and see where it's crashing?
>
> Charles
>
>
> Gregory Najda wrote:
> > On Windows, the version in the CVS crashes a couple seconds after I
> > create a room. So does the 2.5rc2 source code in the sourceforge
> > release. The precompiled 2.5rc2 Windows release works fine, however.
> > Any idea what the deal with that is?
> >
> > On Mon, Jul 27, 2009 at 6:00 PM, Josh <axl...@gm...
> > <mailto:axl...@gm...>> wrote:
> >
> >     The old (stable) version is in the CVS.
> >     The new unfinished version is in SVN.
> >
> >     Gregory Najda wrote:
> >     > Where can I find the code for the stable version that's currently
> >     > running on smonline.us <http://smonline.us>
> >     <http://smonline.us>? What I am most interested
> >     > in is extending the protocol so that more than just artist,
> >     title, and
> >     > subtitle is used to identify which stepfile to use. I'd like to get
> >     > this change implemented on what the server actually runs and in
> >     the SM
> >     > client relatively soon so that players can benefit from it, without
> >     > having to finish up the new SMO version first.
> >     >
> >
> ------------------------------------------------------------------------
> >     >
> >     >
> >
> ------------------------------------------------------------------------------
> >     >
> >     >
> >
> ------------------------------------------------------------------------
> >     >
> >     > _______________________________________________
> >     > Smonline-devs mailing list
> >     > Smo...@li...
> >     <mailto:Smo...@li...>
> >     > https://lists.sourceforge.net/lists/listinfo/smonline-devs
> >     >
> >
> >
> >
> ------------------------------------------------------------------------------
> >     Let Crystal Reports handle the reporting - Free Crystal Reports
> >     2008 30-Day
> >     trial. Simplify your report design, integration and deployment -
> >     and focus on
> >     what you do best, core application coding. Discover what's new with
> >     Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> >     _______________________________________________
> >     Smonline-devs mailing list
> >     Smo...@li...
> >     <mailto:Smo...@li...>
> >     https://lists.sourceforge.net/lists/listinfo/smonline-devs
> >
> >
> > ------------------------------------------------------------------------
> >
> >
> ------------------------------------------------------------------------------
> > Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day
> > trial. Simplify your report design, integration and deployment - and
> focus on
> > what you do best, core application coding. Discover what's new with
> > Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Smonline-devs mailing list
> > Smo...@li...
> > https://lists.sourceforge.net/lists/listinfo/smonline-devs
> >
>
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Smonline-devs mailing list
> Smo...@li...
> https://lists.sourceforge.net/lists/listinfo/smonline-devs
>

Re: [Smonline-devs] Stable version?

[Charles L. <ch...@cn...>]

1) What compiler are you using for it?
2) Uninitialized values changed behavior between VC6 and all .NET
MSVC's.  Using Valgrind in Linux should be able to point the problem out
instantly.
3) Debugger and see where it's crashing?

Charles


Gregory Najda wrote:
> On Windows, the version in the CVS crashes a couple seconds after I
> create a room. So does the 2.5rc2 source code in the sourceforge
> release. The precompiled 2.5rc2 Windows release works fine, however.
> Any idea what the deal with that is?
>
> On Mon, Jul 27, 2009 at 6:00 PM, Josh <axl...@gm...
> <mailto:axl...@gm...>> wrote:
>
>     The old (stable) version is in the CVS.
>     The new unfinished version is in SVN.
>
>     Gregory Najda wrote:
>     > Where can I find the code for the stable version that's currently
>     > running on smonline.us <http://smonline.us>
>     <http://smonline.us>? What I am most interested
>     > in is extending the protocol so that more than just artist,
>     title, and
>     > subtitle is used to identify which stepfile to use. I'd like to get
>     > this change implemented on what the server actually runs and in
>     the SM
>     > client relatively soon so that players can benefit from it, without
>     > having to finish up the new SMO version first.
>     >
>     ------------------------------------------------------------------------
>     >
>     >
>     ------------------------------------------------------------------------------
>     >
>     >
>     ------------------------------------------------------------------------
>     >
>     > _______________________________________________
>     > Smonline-devs mailing list
>     > Smo...@li...
>     <mailto:Smo...@li...>
>     > https://lists.sourceforge.net/lists/listinfo/smonline-devs
>     >
>
>
>     ------------------------------------------------------------------------------
>     Let Crystal Reports handle the reporting - Free Crystal Reports
>     2008 30-Day
>     trial. Simplify your report design, integration and deployment -
>     and focus on
>     what you do best, core application coding. Discover what's new with
>     Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>     _______________________________________________
>     Smonline-devs mailing list
>     Smo...@li...
>     <mailto:Smo...@li...>
>     https://lists.sourceforge.net/lists/listinfo/smonline-devs
>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> ------------------------------------------------------------------------
>
> _______________________________________________
> Smonline-devs mailing list
> Smo...@li...
> https://lists.sourceforge.net/lists/listinfo/smonline-devs
>   

Re: [Smonline-devs] Stable version?

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

On Windows, the version in the CVS crashes a couple seconds after I create a
room. So does the 2.5rc2 source code in the sourceforge release. The
precompiled 2.5rc2 Windows release works fine, however. Any idea what the
deal with that is?

On Mon, Jul 27, 2009 at 6:00 PM, Josh <axl...@gm...> wrote:

> The old (stable) version is in the CVS.
> The new unfinished version is in SVN.
>
> Gregory Najda wrote:
> > Where can I find the code for the stable version that's currently
> > running on smonline.us <http://smonline.us>? What I am most interested
> > in is extending the protocol so that more than just artist, title, and
> > subtitle is used to identify which stepfile to use. I'd like to get
> > this change implemented on what the server actually runs and in the SM
> > client relatively soon so that players can benefit from it, without
> > having to finish up the new SMO version first.
> > ------------------------------------------------------------------------
> >
> >
> ------------------------------------------------------------------------------
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Smonline-devs mailing list
> > Smo...@li...
> > https://lists.sourceforge.net/lists/listinfo/smonline-devs
> >
>
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Smonline-devs mailing list
> Smo...@li...
> https://lists.sourceforge.net/lists/listinfo/smonline-devs
>

Re: [Smonline-devs] Stable version?

[Josh <axl...@gm...>]

The old (stable) version is in the CVS.
The new unfinished version is in SVN.

Gregory Najda wrote:
> Where can I find the code for the stable version that's currently 
> running on smonline.us <http://smonline.us>? What I am most interested 
> in is extending the protocol so that more than just artist, title, and 
> subtitle is used to identify which stepfile to use. I'd like to get 
> this change implemented on what the server actually runs and in the SM 
> client relatively soon so that players can benefit from it, without 
> having to finish up the new SMO version first.
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> Smonline-devs mailing list
> Smo...@li...
> https://lists.sourceforge.net/lists/listinfo/smonline-devs
>   

[Smonline-devs] Stable version?

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

Where can I find the code for the stable version that's currently running on
smonline.us? What I am most interested in is extending the protocol so that
more than just artist, title, and subtitle is used to identify which
stepfile to use. I'd like to get this change implemented on what the server
actually runs and in the SM client relatively soon so that players can
benefit from it, without having to finish up the new SMO version first.

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.

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

[Josh <axl...@gm...>]

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!
>
> I'd be glad to help you guys get the new code finished and stable and 
> be the Windows maintainer. To start, I've fixed compilation on 
> Windows, created a VS 2008 solution and project file, and made a 
> couple minor changes. I've placed the patch at 
> http://www.cs.stevens.edu/~gnajda/SMO/windows_and_cleanup_249.patch 
> <http://www.cs.stevens.edu/%7Egnajda/SMO/windows_and_cleanup_249.patch> 
> (I'm not sure if attachments get through the mailing list).
>
It will take me a while to comb through the changes.  I would me more 
than happy to add you to the project.
> A summary of the changes:
> - Created VS 2008 solution and project files.
> - Fixed Windows compile, eliminated most warnings.
> - Added copy assignment to DataContainer
>
> - DataContainer: changed
> //m_data = new char[m_numElements];
> to
> m_data = new T[m_numElements]; // uhhhh...this is correct and not the 
> above, right?
>
Yes.

> - Rewrote much of ezSocketsPacket, using a vector instead of an array 
> pointer. Compiler-supplied copying behavior was not correct with an 
> array pointer. I could have either written a copy constructor and copy 
> assignment or made it so the compiler-generated copy functions are 
> correct. The less manual memory management, the better, so I did the 
> latter. Some functions return packets. When you return an object, what 
> normally happens is that the object gets copied using the copy 
> constructor, the copy is the return value, and the original gets 
> destructed. Some compilers optimize away the copy. MSVC does this, but 
> only with optimizations on. With optimizations off (in the Debug 
> configuration), it does not do this optimzation.
I'm a little cautious when making changes to ezSocketsPacket simply 
because it needs to be compatible with previous versions.  You may want 
to talk to Charles about this, as he wrote most of it.
>
> - 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.
>
> - Misc. code cleanup.
>
> Some comments:
>
> - Why create your own smart pointer and thread classes instead of 
> using the ones in boost? "AutoPtr" in the name is misleading for a 
> smart pointer that's a reference-counting pointer and not one that 
> deletes the object as soon as the pointer goes out of scope.
AutoPtr deletes the pointer when the reference count reaches 0. Please 
look at AutoPtr::DecrementReference.
> - Prefer vector and string to pointers. The speed cost is not as great 
> as you think and it eliminates a class of bugs.
Note that an EzSockets class can not be placed in a vector.  Copying the 
class will break the socket connection.
> - If a class has a destructor, it should also have both a copy 
> constructor and copy assignment or be uncopyable (since we're already 
> using boost, inherit from boost::noncopyable). Objects returned by 
> functions by value (not by pointer) must have a copy constructor.
> - Don't use variable-length arrays - that's a C99 feature and is not 
> standard C++ (and doesn't compile with MSVC). Use vectors or strings 
> instead.
I have since discovered that variable length arrays are not standard C++.
In the past we have discovered some serious issues with std::vector in 
Visual Studio 2005 and up.  I forget the exact circumstances but it was 
something along the lines of, when storing pointers in a vector, if a 
pointer is deleted, Visual Studio would somehow remove that specific 
index from the vector.  That's why we have been steering a way from vectors.
>
> -#if defined(WIN32)
> typedef unsigned int uint16_t; - wtf? unsigned int is 32 bits!!!
>
WTF indeed.
> So, what remains to be done? And if there's a concensus on how to 
> implement the protocol extension I mentioned, could it be implemented 
> on smonline.us <http://smonline.us>? I am very interested in getting 
> the extension implemented because I host weekly Stepmania meetups for 
> members of a forum and the problem of only title, subtitle, and artist 
> being used to identify stepfiles keeps us from playing some of our 
> favorites. I've already made the necessary changes to the Stepmania 
> client, although that might have to change if a stepfile with 
> added/removed charts is to be considered the "same" stepfile. 
> (http://www.stepmania.com/forums/showthread.php?t=19844)
I would say tack the extension on as a different packet type and make it 
optional, so that it is backwards compatible.
>
> A bit about myself: My name is Greg Najda. I recently graduated from 
> Stevens Institute of Technology as a computer science major. I'm 
> currently unemployed, so I have plenty of time to work on this. :)
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge  
> This is your chance to win up to $100,000 in prizes! For a limited time, 
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize  
> details at: http://p.sf.net/sfu/Challenge
> ------------------------------------------------------------------------
>
> _______________________________________________
> Smonline-devs mailing list
> Smo...@li...
> https://lists.sourceforge.net/lists/listinfo/smonline-devs
>   

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

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

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.

I'd be glad to help you guys get the new code finished and stable and be the
Windows maintainer. To start, I've fixed compilation on Windows, created a
VS 2008 solution and project file, and made a couple minor changes. I've
placed the patch at
http://www.cs.stevens.edu/~gnajda/SMO/windows_and_cleanup_249.patch (I'm not
sure if attachments get through the mailing list).

A summary of the changes:
- Created VS 2008 solution and project files.
- Fixed Windows compile, eliminated most warnings.
- Added copy assignment to DataContainer

- DataContainer: changed
//m_data = new char[m_numElements];
to
m_data = new T[m_numElements]; // uhhhh...this is correct and not the above,
right?

- Rewrote much of ezSocketsPacket, using a vector instead of an array
pointer. Compiler-supplied copying behavior was not correct with an array
pointer. I could have either written a copy constructor and copy assignment
or made it so the compiler-generated copy functions are correct. The less
manual memory management, the better, so I did the latter. Some functions
return packets. When you return an object, what normally happens is that the
object gets copied using the copy constructor, the copy is the return value,
and the original gets destructed. Some compilers optimize away the copy.
MSVC does this, but only with optimizations on. With optimizations off (in
the Debug configuration), it does not do this optimzation.

- 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.

- Misc. code cleanup.

Some comments:

- Why create your own smart pointer and thread classes instead of using the
ones in boost? "AutoPtr" in the name is misleading for a smart pointer
that's a reference-counting pointer and not one that deletes the object as
soon as the pointer goes out of scope.
- Prefer vector and string to pointers. The speed cost is not as great as
you think and it eliminates a class of bugs.
- If a class has a destructor, it should also have both a copy constructor
and copy assignment or be uncopyable (since we're already using boost,
inherit from boost::noncopyable). Objects returned by functions by value
(not by pointer) must have a copy constructor.
- Don't use variable-length arrays - that's a C99 feature and is not
standard C++ (and doesn't compile with MSVC). Use vectors or strings
instead.

-#if defined(WIN32)
typedef unsigned int uint16_t; - wtf? unsigned int is 32 bits!!!

So, what remains to be done? And if there's a concensus on how to implement
the protocol extension I mentioned, could it be implemented on smonline.us?
I am very interested in getting the extension implemented because I host
weekly Stepmania meetups for members of a forum and the problem of only
title, subtitle, and artist being used to identify stepfiles keeps us from
playing some of our favorites. I've already made the necessary changes to
the Stepmania client, although that might have to change if a stepfile with
added/removed charts is to be considered the "same" stepfile. (
http://www.stepmania.com/forums/showthread.php?t=19844)

A bit about myself: My name is Greg Najda. I recently graduated from Stevens
Institute of Technology as a computer science major. I'm currently
unemployed, so I have plenty of time to work on this. :)