Re: [btech-discussion] Note about modifying hudinfo

[Cord A. <ki...@bs...>]

So where's the problem? We have a version number, so the clients should just
validate against the max version number they support, and if the MUX is send
unsupported data, then the client should just notify the user and quit. It ain't
that hard and it's a fairly standard action to take by a piece of software.

    -C-

Anthony Parker wrote:

> Hudinfo already has a 'version' command that returns a major and minor
> version number. The major number changes when hudinfo changes enough to
> break current clients, and the minor version number changes when hudinfo
> adds new functionality that won't affect current clients.
>
> The issue isn't me changing the source code, it's that everyone who is using
> the current version of Thud won't be able to use it anymore, forcing
> everyone to (probably) think Thud broke and go get a new version. As more
> and more people download Thud, or other programs that may use hudinfo, it
> becomes more and more difficult to justify changing a command like hudinfo
> t.
>
> So, I propose that we:
>
> 1. Deal with hudinfo the way it is, or add a minor command to get the
> current map name. As Focus mentioned earlier, it's also possible to simply
> have the user specify when the map has changed, since they generally know
> this. You could also look for drastic immediate changes in location and map
> size (ie, RS to hangar.map) or terrain. You can tell if a map is 'small' if
> you request a hudinfo t at 40 hexes high and get one that's 10.
>
> 2. Note this and a bunch of other improvements (I have several for hudinfo c
> and gs), and implement them all together at some future point. This means
> that we don't have to change the major version number 10 times in the next 3
> months but maybe only once.
>
> - Tony
>
> On 8/19/02 4:17 AM, "Cord Awtry" <ki...@bs...> wrote:
>
> > You know... there's a pretty damn easy fix to all of this. Just prepend
> > easy command with a simple version number. When stuff is changed to the
> > format, the version number is bumped. Then clients need to be changed
> > one additional time... that time being _right now_ so it knows about the
> > version numbers. Future changes are up to the developer of the client
> > because he/she/it only has to implement each version changes...
> >
> > It's the rigors of communication through plain text strings that are
> > parsed.
> >
> > -C-
> >
> > -----Original Message-----
> > From: bte...@li...
> > [mailto:bte...@li...] On Behalf Of
> > Tuncay Goncuoglu
> > Sent: Monday, August 19, 2002 6:10 AM
> > To: BTech Discussion
> > Subject: RE: [btech-discussion] Note about modifying hudinfo
> >
> >
> > Hi T,
> >
> > Normally, you would be right. However, the only current client that uses
> > hudinfo is your thud. Yes, I'm working on hudinfo for my client, and
> > yes, I'll have to modify hudinfo t parsing, but my clients hudinof
> > implementation is far from complete (and currently unreleased) anyway.
> >
> > Is there there any other client that I dont know of ?
> >
> > Regards,
> > ---
> > Tuncay Göncüog˜lu
> > Senior Developer
> >
> > tgo...@ma...
> > GSM:+90-532-6176445
> > Fax:+90-533-9830363
> >
> >
> >
> >> -----Original Message-----
> >> From: bte...@li...
> >> [mailto:bte...@li...] On
> >> Behalf Of Anthony Parker
> >> Sent: Monday, August 19, 2002 2:03 AM
> >> To: bte...@li...
> >> Subject: [btech-discussion] Note about modifying hudinfo
> >>
> >>
> >> Just so everyone's clear on some things, we should /really/
> >> avoid modifying
> >> hudinfo so that it breaks current clients. It's easy enough to update
> >> current code, sure, but as it gets more popular, there are
> >> people out there
> >> using older versions of HUDs that will probably have to stop
> >> working because
> >> of a change in the core format of commands like 'hudinfo t'.
> >>
> >> - Tony
> >>
> >>
> >>
> >> -------------------------------------------------------
> >> This sf.net email is sponsored by: OSDN - Tired of that same old
> >> cell phone?  Get a new here for FREE!
> >> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> >> _______________________________________________
> >> btech-discussion mailing list
> >> bte...@li...
> >> https://lists.sourceforge.net/lists/listinfo/btech-discussion
> >>
> >>
> >>
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by: OSDN - Tired of that same old
> > cell phone?  Get a new here for FREE!
> > https://www.inphonic.com/r.asp?r=urceforge1&refcode1=3390
> > _______________________________________________
> > btech-discussion mailing list
> > bte...@li...
> > https://lists.sourceforge.net/lists/listinfo/btech-discussion
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by: OSDN - Tired of that same old
> > cell phone?  Get a new here for FREE!
> > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> > _______________________________________________
> > btech-discussion mailing list
> > bte...@li...
> > https://lists.sourceforge.net/lists/listinfo/btech-discussion
> >
>
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> btech-discussion mailing list
> bte...@li...
> https://lists.sourceforge.net/lists/listinfo/btech-discussion