Re: [btech-discussion] Re: Note about modifying hudinfo

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

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
>