Re: [btech-discussion] Note about modifying hudinfo

[Anthony P. <ton...@ma...>]

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