Thread: RE: [btech-discussion] Note about modifying hudinfo
Brought to you by:
twouters
Menu
▾
▴
btech-discussion
|
From: Tuncay G. <tgo...@ma...> - 2002-08-19 10:10:07
|
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=F6nc=FCo=F0lu Senior Developer tgo...@ma... GSM:+90-532-6176445 Fax:+90-533-9830363 > -----Original Message----- > From: bte...@li...=20 > [mailto:bte...@li...] On=20 > Behalf Of Anthony Parker > Sent: Monday, August 19, 2002 2:03 AM > To: bte...@li... > Subject: [btech-discussion] Note about modifying hudinfo >=20 >=20 > Just so everyone's clear on some things, we should /really/=20 > 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=20 > people out there > using older versions of HUDs that will probably have to stop=20 > working because > of a change in the core format of commands like 'hudinfo t'. >=20 > - Tony >=20 >=20 >=20 > ------------------------------------------------------- > 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=3Dsourceforge1&refcode1=3Dvs3390 > _______________________________________________ > btech-discussion mailing list > bte...@li... > https://lists.sourceforge.net/lists/listinfo/btech-discussion >=20 >=20 >=20 |
|
From: Cord A. <ki...@bs...> - 2002-08-19 11:18:22
|
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=F6nc=FCo=F0lu Senior Developer tgo...@ma... GSM:+90-532-6176445 Fax:+90-533-9830363 > -----Original Message----- > From: bte...@li...=20 > [mailto:bte...@li...] On=20 > Behalf Of Anthony Parker > Sent: Monday, August 19, 2002 2:03 AM > To: bte...@li... > Subject: [btech-discussion] Note about modifying hudinfo >=20 >=20 > Just so everyone's clear on some things, we should /really/=20 > 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=20 > people out there > using older versions of HUDs that will probably have to stop=20 > working because > of a change in the core format of commands like 'hudinfo t'. >=20 > - Tony >=20 >=20 >=20 > ------------------------------------------------------- > 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=3Dsourceforge1&refcode1=3Dvs3390 > _______________________________________________ > btech-discussion mailing list > bte...@li... > https://lists.sourceforge.net/lists/listinfo/btech-discussion >=20 >=20 >=20 ------------------------------------------------------- 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=3Durceforge1&refcode1=3D3390 _______________________________________________ btech-discussion mailing list bte...@li... https://lists.sourceforge.net/lists/listinfo/btech-discussion |
|
From: Anthony P. <as...@ma...> - 2002-08-19 16:51:23
|
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 usin= g 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... >=20 > It's the rigors of communication through plain text strings that are > parsed. >=20 > -C- >=20 > -----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 >=20 >=20 > Hi T, >=20 > 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. >=20 > Is there there any other client that I dont know of ? >=20 > Regards, > --- > Tuncay G=F6nc=FCog=98lu > Senior Developer >=20 > tgo...@ma... > GSM:+90-532-6176445 > Fax:+90-533-9830363 >=20 >=20 >=20 >> -----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 >>=20 >>=20 >> 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'. >>=20 >> - Tony >>=20 >>=20 >>=20 >> ------------------------------------------------------- >> 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=3Dsourceforge1&refcode1=3Dvs3390 >> _______________________________________________ >> btech-discussion mailing list >> bte...@li... >> https://lists.sourceforge.net/lists/listinfo/btech-discussion >>=20 >>=20 >>=20 >=20 >=20 >=20 > ------------------------------------------------------- > 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=3Durceforge1&refcode1=3D3390 > _______________________________________________ > btech-discussion mailing list > bte...@li... > https://lists.sourceforge.net/lists/listinfo/btech-discussion >=20 >=20 >=20 > ------------------------------------------------------- > 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=3Dsourceforge1&refcode1=3Dvs3390 > _______________________________________________ > btech-discussion mailing list > bte...@li... > https://lists.sourceforge.net/lists/listinfo/btech-discussion >=20 |
|
From: Cord A. <ki...@bs...> - 2002-08-19 19:30:50
|
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üoglu
> > 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
|
|
From: Anthony P. <ton...@ma...> - 2002-08-19 20:06:32
|
Like I've said 3 times now, I don't see any reason to break all of those clients already. Let's wait until we have a lot of changes to make, then make them all at once, to avoid having to make everyone upgrade constantly. - Tony On 8/19/02 12:30 PM, "Cord Awtry" <ki...@bs...> wrote: > So where's the problem? We have a version number, so the clients should j= ust > validate against the max version number they support, and if the MUX is s= end > unsupported data, then the client should just notify the user and quit. I= t > ain't > that hard and it's a fairly standard action to take by a piece of softwar= e. >=20 > -C- >=20 > Anthony Parker wrote: >=20 >> 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. >>=20 >> The issue isn't me changing the source code, it's that everyone who is u= sing >> 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 mor= e >> and more people download Thud, or other programs that may use hudinfo, i= t >> becomes more and more difficult to justify changing a command like hudin= fo >> t. >>=20 >> So, I propose that we: >>=20 >> 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 simp= ly >> have the user specify when the map has changed, since they generally kno= w >> 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. >>=20 >> 2. Note this and a bunch of other improvements (I have several for hudin= fo c >> and gs), and implement them all together at some future point. This mean= s >> that we don't have to change the major version number 10 times in the ne= xt 3 >> months but maybe only once. >>=20 >> - Tony >>=20 >> On 8/19/02 4:17 AM, "Cord Awtry" <ki...@bs...> wrote: >>=20 >>> 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 th= e >>> version numbers. Future changes are up to the developer of the client >>> because he/she/it only has to implement each version changes... >>>=20 >>> It's the rigors of communication through plain text strings that are >>> parsed. >>>=20 >>> -C- >>>=20 >>> -----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 >>>=20 >>>=20 >>> Hi T, >>>=20 >>> Normally, you would be right. However, the only current client that use= s >>> 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. >>>=20 >>> Is there there any other client that I dont know of ? >>>=20 >>> Regards, >>> --- >>> Tuncay G=F6nc=FCog=98lu >>> Senior Developer >>>=20 >>> tgo...@ma... >>> GSM:+90-532-6176445 >>> Fax:+90-533-9830363 >>>=20 >>>=20 >>>=20 >>>> -----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 >>>>=20 >>>>=20 >>>> 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'. >>>>=20 >>>> - Tony >>>>=20 >>>>=20 >>>>=20 >>>> ------------------------------------------------------- >>>> 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=3Dsourceforge1&refcode1=3Dvs3390 >>>> _______________________________________________ >>>> btech-discussion mailing list >>>> bte...@li... >>>> https://lists.sourceforge.net/lists/listinfo/btech-discussion >>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>>=20 >>> ------------------------------------------------------- >>> 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=3Durceforge1&refcode1=3D3390 >>> _______________________________________________ >>> btech-discussion mailing list >>> bte...@li... >>> https://lists.sourceforge.net/lists/listinfo/btech-discussion >>>=20 >>>=20 >>>=20 >>> ------------------------------------------------------- >>> 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=3Dsourceforge1&refcode1=3Dvs3390 >>> _______________________________________________ >>> btech-discussion mailing list >>> bte...@li... >>> https://lists.sourceforge.net/lists/listinfo/btech-discussion >>>=20 >>=20 >> ------------------------------------------------------- >> 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=3Dsourceforge1&refcode1=3Dvs3390 >> _______________________________________________ >> btech-discussion mailing list >> bte...@li... >> https://lists.sourceforge.net/lists/listinfo/btech-discussion >=20 |
|
From: Ernst B. <e.b...@xe...> - 2002-08-19 22:06:55
|
Hi all, > From: Anthony Parker <as...@ma...> > > 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 The proposed change was adding two additional fields at the end of the first line returned by hudinfo t. There was never any request to change the "core format" of the result or to change the meaning of the other parameters transmitted. So I don't see any chance that this change could break any client (in fact, I would consider any client as broken if it doesn't cope with such changes) Most people implementing a hudinfo parser would split the received values first (using e.g. StringTokenizer) and then evaluate those values they need. Those implementations wouldn't be affected by the proposed changes. In order to make future enhancements to hudinfo painless, this should be explicitly stated in the hudinfo docs: New commands or additional information appended for existing commands: minor version increase Change in existing parameters or removal of commands: major version increase In other words: Hudinfo implementations simply should ignore values they don't know about... Bye Ernst |
|
From: Anthony P. <as...@ma...> - 2002-08-19 22:27:16
|
Well, we should avoid making any assumptions about how the strings from hudinfo are parsed, as that is up to the client and could be language or platform dependant. The reason that hudinfo is so explicitly laid out is to avoid problems arising from assumptions. However, changing the hudinfo document to specify that any fields after the ones specified in the document should be ignored seems like a good idea and solves the problem of assuming things, so I think that'll work great. Also, the minor version number should be incremented with changes like this, to reflect that the info is there (of course), and the hudinfo spec already notes that clients should not refuse to work because of a higher minor version number. We should come up with some further changes while we have the opportunity and do them all at once. For example, hudinfo c doesn't display which contact is locked (if any), and hudinfo gs doesn't display your own jump heading - but hudinfo c shows it for other contacts. I also think that we should have the option to get armor scan and weapon scan in one command with one 'scan' notification on the enemy, maybe 'hudinfo awsc' that prints out both 'asc' and 'wsc', although this last one is really more of a minor concern. - Tony On 8/19/02 3:15 PM, "Ernst Bachmann" <e.b...@xe...> wrote: > Hi all, > >> From: Anthony Parker <as...@ma...> >> >> 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 > > The proposed change was adding two additional fields at the end of the first > line returned by hudinfo t. > There was never any request to change the "core format" of the result or to > change the meaning of the other parameters transmitted. > So I don't see any chance that this change could break any client > (in fact, I would consider any client as broken if it doesn't cope with such > changes) > > Most people implementing a hudinfo parser would split the received values > first (using e.g. StringTokenizer) and then evaluate those values they need. > Those implementations wouldn't be affected by the proposed changes. > > In order to make future enhancements to hudinfo painless, this should be > explicitly stated in the hudinfo docs: > New commands or additional information appended for existing commands: minor > version increase > > Change in existing parameters or removal of commands: major version increase > > In other words: Hudinfo implementations simply should ignore values they don't > know about... > > Bye > Ernst > > > ------------------------------------------------------- > 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 > |
Thanks for helping keep SourceForge clean.
X