btech-discussion

[btech-discussion] Newbie

[Ricardo M. <dar...@ho...>]

Hi everyone!

I´m not sure if this is the right place to ask questions but I´m really new 
to Battletech MUX (I´ve been playing for 3 months now) and I´m trying to set 
up a tentative server.

I downloaded the code at Sourceforge and tried to compile it but got the 
following messages:

$ make install
(cd event ; make)
make[1]: Entering directory `/home/Ricardo/btech/btechmux-1.4.3/event'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/home/Ricardo/btech/btechmux-1.4.3/event'
(cd misc ; make)
make[1]: Entering directory `/home/Ricardo/btech/btechmux-1.4.3/misc'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/home/Ricardo/btech/btechmux-1.4.3/misc'
(cd tree ; make)
make[1]: Entering directory `/home/Ricardo/btech/btechmux-1.4.3/tree'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/home/Ricardo/btech/btechmux-1.4.3/tree'
(CDPATH= ; cd src ; make)
make[1]: Entering directory `/home/Ricardo/btech/btechmux-1.4.3/src'
gcc -g -O2 -Wall -Wno-unused -DMYFIFO -DMEMORY_BASED -DBT_ENABLED 
-DHUDINFO_SUPP
ORT -g -O2   -DMEMORY_BASED     -I../include -I. -Ihcode/include -c bsd.c
bsd.c: In function `shutdownsock':
bsd.c:753: warning: dereferencing type-punned pointer will break 
strict-aliasing
rules
bsd.c: In function `sighandler':
bsd.c:1240: warning: passing arg 1 of `wait' from incompatible pointer type
bsd.c:1244: error: invalid operands to binary >>
make[1]: *** [bsd.o] Error 1
make[1]: Leaving directory `/home/Ricardo/btech/btechmux-1.4.3/src'
make: *** [all] Error 2
$

Can anybody help me? Maybe point me somewhere else to get help?

Thanks

Ricardo

_________________________________________________________________
MSN Messenger: instale grátis e converse com seus amigos. 
http://messenger.msn.com.br

RE: [btech-discussion] Ping?

[Bowen, J. (711) <Jas...@pr...>]

ICMP echo reply back at you

-----Original Message-----
From: ke...@bt... [mailto:ke...@bt...]
Sent: Tuesday, October 28, 2003 11:32 PM
To: bte...@li...
Subject: [btech-discussion] Ping?


Is there anyone still on here?


NOTICE:  This electronic mail message is intended exclusively for the individual or entity to which it is addressed.  This message, together with any attachment, may contain confidential and privileged information.  Any unauthorized review, use, print, retain, copy, disclosure or distribution is strictly prohibited.  If you have received this message in error, please immediately advise the sender by reply email message to the sender and delete all copies of this message.  Thank you.

Re: [btech-discussion] 3030/3065 Source Merging?

[Thomas W. <th...@xs...>]

On Wed, Oct 29, 2003 at 07:26:29AM -0500, ke...@bt... wrote:

>     Now that I know I'm not alone here, I figure I'd ask a question that
>     some of us are no doubt wondering. It was recently announced that Kip
>     would be taking the reigns of 3065 as Head Wizard and performing some
>     code merging between the two codebases. I'm curious to know what kind
>     of improvements this will bring over the base 3030 dist. Along with
>     that, when are we likely to start seeing these changes in?

>     I'm a bit curious about this (as I'm sure others are too) and from
>     what I've seen, 3065 had some very stable, cleanly running code (from
>     the player side of things). It's good to see some swapping around
>     going on, now if you could get Deej to do that... :)

Well, I'm not sure howmuch of the actual code will make it into the OS tree.
It may look clean from the player perspective, but this is more to do with
the surrounding supporting softcode than the actual hardcode. But the idea
is to replace the 3065 binary with one compiled from the opensource tree,
with some different configuration settings, and have it change very little
for the people playing 3065.

I've made a large diff between 3065 source and the MUX source it was based
on (more or less) and am currently working that through to find the actual
changes that need incorporating. It'll take me a while to finish it, but
it'll be merged eventually.

As for 3029, well, you have more influence there than me. Fingon already
agreed to a re-release of the original MUX source under the 3030MUX license,
provided he doesn't have to do anything, so the 'big reason' why 3029's
source is closed would be removed, but it's not a high priority to me. I
plan on adding some of the cool features from 3029 into the OS tree in a
different manner, and I don't at all like how AT2 is implemented there, so I
don't care much for 3029's source at the moment :)

-- 
Thomas Wouters <th...@xs...>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

[btech-discussion] 3030/3065 Source Merging?

[<ke...@bt...>]

    Now that I know I'm not alone here, I figure I'd ask a question that =
some of us are no doubt wondering. It was recently announced that Kip =
would be taking the reigns of 3065 as Head Wizard and performing some =
code merging between the two codebases. I'm curious to know what kind of =
improvements this will bring over the base 3030 dist. Along with that, =
when are we likely to start seeing these changes in?

    I'm a bit curious about this (as I'm sure others are too) and from =
what I've seen, 3065 had some very stable, cleanly running code (from =
the player side of things). It's good to see some swapping around going =
on, now if you could get Deej to do that... :)

[btech-discussion] Ping?

[Griffin <rs...@ma...>]

Ping passed :)
 

RE: [btech-discussion] Ping?

[Tuncay G. <tu...@ma...>]

 
pong

-----Original Message-----
From: ke...@bt... [mailto:ke...@bt...] 
Sent: Wednesday, October 29, 2003 6:32 AM
To: bte...@li...
Subject: [btech-discussion] Ping?


Is there anyone still on here?

[btech-discussion] Ping?

[<ke...@bt...>]

Is there anyone still on here?

[btech-discussion] BTECH.SOURCEFORGE.NET

[Sarah W. <re...@tm...>]

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE></TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dgb2312"><!-- =
Ap -->
<STYLE type=3Dtext/css>TD {
	FONT-SIZE: 11px; COLOR: #000000; FONT-FAMILY: verdana, arial, helvetica
}
</STYLE>

<META content=3D"MSHTML 6.00.2722.900" name=3DGENERATOR></HEAD>
<BODY bgColor=3D#ffffff>
<TABLE cellSpacing=3D0 cellPadding=3D0 width=3D600 border=3D0>
  <TBODY>
  <TR>
    <TD>Hi<BR><BR>I visited <A 
      href=3D=
"http://www.trafficmagnet.com/signup/index.html">BTECH.SOURCEFORGE.NET</A>, =
and noticed that you're not listed on some search engines! I 
      think we can offer you a service which can help you increase traffic =
and 
      the number of visitors to your website.<BR><BR>I would like to =
introduce 
      you to <A 
      href=3D=
"http://www.trafficmagnet.com/signup/index.html">Trafficmagnet.com</A>. 
      We offer a unique technology that will submit your website to over =
300,000 
      search engines and directories every month.<BR><BR>
      <TABLE cellSpacing=3D0 cellPadding=3D0 width=3D398 align=3Dcenter =
border=3D0>
        <TBODY>
        <TR>
          <TD><A href=3D"http://www.trafficmagnet.com/signup/index.html"><IMG =

            height=3D136 src=3D"http://www.trafficmagnet.com/img/img_tm.gif" =
width=3D137 border=3D0></A>&nbsp;</TD>
          <TD><A href=3D"http://www.trafficmagnet.com/signup/index.html"><IMG =

            height=3D141 src=3D=
"http://image10.trafficmagnet.net/img4/HERCULES-198/001/212/cko.jpg" width=3D=
197 border=3D1></A></TD>
          <TD vAlign=3Dbottom><A 
            href=3D"http://www.trafficmagnet.com/signup/index.html"><IMG 
            height=3D136 src=3D=
"http://www.trafficmagnet.com/img/img_signup.gif" width=3D62 
      border=3D0></A></TD></TR></TBODY></TABLE><BR>You'll be surprised by the =
low 
      cost, and by how effective this website promotion method can be. 
      <BR><BR>To find out more about TrafficMagnet and the cost for =
submitting 
      your website to over 300,000 search engines and directories, visit <A 
      href=3D=
"http://www.trafficmagnet.com/signup/index.html">www.trafficmagnet.com</A>. 
      <BR><BR>I would love to hear from you. <BR><BR><BR>Best 
      Regards,<BR><BR>Sarah Williams <BR>Sales and Marketing <BR>E-mail: 
      sar...@tm... <BR><A 
      href=3D=
"http://www.trafficmagnet.com/signup/index.html">http://www.trafficmagnet.com=
</A> 

      <P>This email was sent to bte...@li.... We apologize if this email =

      has reached you in error.<BR>We honor all removal requests. Please <A 
      href=3D"http://optout.trafficmagnet.com/optout/Action/OptOut?email=3D=
bte...@li...&url=3D btech.sourceforge.net">click 
      here</A> to be removed from our mailing 
list.</P></TD></TR></TBODY></TABLE></BODY></HTML>

[btech-discussion] Resource Site

[Greg T. <gt...@so...>]

I've been playing with a BTMux resource site for some time now in hopes =
of spreading what information I've scrounged together over the years =
with others. I've posted up some basic GPL'd code for those who'd like =
it, along with some other useful downloads and links. This is a fairly =
recent thing that's only been running in its current state for about two =
months.

If you'd like to contribute some code or submit news when your =
respective sites make major updates (new binaries or scenario changes), =
please feel free to stop by and pitch something in. It is my hope that =
this may help in bringing some prospective new admins (or help existing =
ones) therefore revitalizing BTMux somewhat.

I can't remember if I've already posted this to here or not, so sorry if =
this is a duplicate. You may view the site at:

http://dott.sourceforge.net

Hope to see you there!

[btech-discussion] Resource Site

[Greg T. <gt...@so...>]

I've been playing with a BTMux resource site for some time now in hopes =
of spreading what information I've scrounged together over the years =
with others. I've posted up some basic GPL'd code for those who'd like =
it, along with some other useful downloads and links. This is a fairly =
recent thing that's only been running in its current state for about two =
months.

If you'd like to contribute some code or submit news when your =
respective sites make major updates (new binaries or scenario changes), =
please feel free to stop by and pitch something in. It is my hope that =
this may help in bringing some prospective new admins (or help existing =
ones) therefore revitalizing BTMux somewhat.

I can't remember if I've already posted this to here or not, so sorry if =
this is a duplicate. You may view the site at:

http://dott.sourceforge.net

Hope to see you there!

[btech-discussion] Minimal DB

[Greg T. <gt...@so...>]

For anyone interested in a side-project, I'm working on a minimal =
database (or more accurately, a game directory) that I will distribute =
on my SourceForge project which I have recently changed over to a sort =
of BattleTechMUX support project which provides some @decomps, =
documentation, and maybe eventually some hardcode patches amongst other =
things.=20

    I could use a softcoder or two to help me establish the basis of =
what a BTMux needs to run in a well equipped minimal db (a little bit of =
an oxymoron). Stuff like a BBS, a basic background infrastructure with =
some organization, some basic globals, etc. I'm making great progress =
because I've done this sort of thing quite a few times (I've helped =
quite a few admins with their BTMuxs only to see them flop and therefore =
have set up the infrastructure on quite a few games :)

    The basic idea I'm attempting is a database that is ready for a =
scenario pending some minor code work on the behalf of the staff such as =
establishing an actual econ, creating the factional code (if applicable) =
and other things such as that. That alone is pretty time consuming and =
will sort of "filter out the crap" so to speak. So I'm not really trying =
to create a ready to go game, I'm providing the foundation.

    The code used in this database will be either mine, code that is =
contributed from others, or open-sourced/shared code.=20

    If you are interested in joining up on this project, visit =
http://dott.sourceforge.net ( Note that the website doesn't have much as =
of yet, I've only started to release code a few days ago.) or telnet to:

Host: dott2.ath.cx
Port: 5555

    If anyone has anything they'd like to see included in this database, =
feel free to reply and give me some more ideas. A few things I had in =
mind:

- A slightly modified Myrddin's BBS with some BT-Specific customizations =
(The IC lock most games have, some additional admin commands, etc)
- A job tracker, courtesy of Anomaly TrekMUSH (It's a great tracker, has =
buckets and also handles bug reports. 3029 currently uses this)
- A MUSH cron system, likely the one included in SGP. I found it to be a =
little nicer than Myrddin's.
- Basic Parents (Room Desc, Mech Parent, etc.)
- A basic set of globals (+finger, @pl, some wiz commands like =
join/summon)
- A basic character generation system
- Sim Center Code
- Some sort of +viewref system (be it a "pod-rider" or a status -> =
attribute piper)
- Registration commands

    I plan on making code that I do for this DB available on the website =
in a text file for those who would like to just @decomp them in to their =
games. I realize that this will likely be of little use to the mature =
games out there, but hopefully we'll have some fledgling BTMuxs sometime =
down the road that can make use of them :)

    Sorry for the spam post, I've been wanting to do this for a very =
long time and I hope it will be of some benefit to the BTMux community. =
We all sorta share a collective playerbase and I'd love to see it grow. =
Some of you may be worried that this may result in a more spread out =
group, which may happen, but there's also an even greater chance it will =
result in more rapid growth due to the fact that there are more than 3-4 =
BTMuxs advertising and pulling in new players.

    Email me back if you have any questions.

[btech-discussion] Minimal DB

[Greg T. <gt...@so...>]

    For anyone interested in a side-project, I'm working on a minimal =
database (or more accurately, a game directory) that I will distribute =
on my SourceForge project which I have recently changed over to a sort =
of BattleTechMUX support project which provides some @decomps, =
documentation, and maybe eventually some hardcode patches amongst other =
things.=20

    I could use a softcoder or two to help me establish the basis of =
what a BTMux needs to run in a well equipped minimal db (a little bit of =
an oxymoron). Stuff like a BBS, a basic background infrastructure with =
some organization, some basic globals, etc. I'm making great progress =
because I've done this sort of thing quite a few times (I've helped =
quite a few admins with their BTMuxs only to see them flop and therefore =
have set up the infrastructure on quite a few games :)

    The basic idea I'm attempting is a database that is ready for a =
scenario pending some minor code work on the behalf of the staff such as =
establishing an actual econ, creating the factional code (if applicable) =
and other things such as that. That alone is pretty time consuming and =
will sort of "filter out the crap" so to speak. So I'm not really trying =
to create a ready to go game, I'm providing the foundation.

    The code used in this database will be either mine, code that is =
contributed from others, or open-sourced/shared code.=20

    If you are interested in joining up on this project, visit =
http://dott.sourceforge.net ( Note that the website doesn't have much as =
of yet, I've only started to release code a few days ago.) or telnet to:

Host: dott2.ath.cx
Port: 5555

    If anyone has anything they'd like to see included in this database, =
feel free to reply and give me some more ideas. A few things I had in =
mind:

- A slightly modified Myrddin's BBS with some BT-Specific customizations =
(The IC lock most games have, some additional admin commands, etc)
- A job tracker, courtesy of Anomaly TrekMUSH (It's a great tracker, has =
buckets and also handles bug reports. 3029 currently uses this)
- A MUSH cron system, likely the one included in SGP. I found it to be a =
little nicer than Myrddin's.
- Basic Parents (Room Desc, Mech Parent, etc.)
- A basic set of globals (+finger, @pl, some wiz commands like =
join/summon)
- A basic character generation system
- Sim Center Code
- Some sort of +viewref system (be it a "pod-rider" or a status -> =
attribute piper)
- Registration commands

    I plan on making code that I do for this DB available on the website =
in a text file for those who would like to just @decomp them in to their =
games. I realize that this will likely be of little use to the mature =
games out there, but hopefully we'll have some fledgling BTMuxs sometime =
down the road that can make use of them :)

    Sorry for the spam post, I've been wanting to do this for a very =
long time and I hope it will be of some benefit to the BTMux community. =
We all sorta share a collective playerbase and I'd love to see it grow. =
Some of you may be worried that this may result in a more spread out =
group, which may happen, but there's also an even greater chance it will =
result in more rapid growth due to the fact that there are more than 3-4 =
BTMuxs advertising and pulling in new players.

    Email me back if you have any questions.

[btech-discussion] HUDINFO 0.7 and CVS

[Thomas W. <th...@xs...>]

I incorporated most of the feedback I got, from this list as well as private
channels, and updated the hudinfo spec and the implementation in CVS. The
new spec is uploaded to http://btech.sf.net/hudinfo.spec.txt, but here are
the major changes:

 - new 'bc' command for building contacts
 - added jump-target x/y to 'gs output
 - added heat to the weapon list
 - added optional map info items to the 't' output
 - required that all strings be non-empty

The latter change is really the biggest change, all the other changes are
100% backward compatible (for compliant implementations of the client side,
in any case.) The requirement for strings not being empty means that some of
the status/ability listings now turn up as ',-,' rather than ',,', possibly
breaking existing clients. The idea is that avoiding empty items eases
parsing and reduces the chance of errors. Do note that (currently, at least)
a string existing only of whitespace is still perfectly valid. Does anyone
expect this to be a problem ?

In addition to the above changes, the CVS implementation contains a few
bugfixes... Most notably the walkspeed and runspeed of 'sgi' were
transposed. 'oops'. If you were relying on their order in effect, rather
than standard, you should keep that in mind. I also fixed some other
glitches. The CVS implementation of hudinfo does support two of the three
map info items in 't' output, optionally, controlled by an @admin toggle.
See the CVS logs for more information.

3030MUX will probably update the binary (and thus switch to hudinfo 0.7) in
a couple of days. If it works out, I'll probably build a 1.4.4 release.

Aside from all that, I'm considering doing some serious work on the CVS HEAD
(but not the stable branch, btmux_1_4-branch) that would leave it in a very
unstable state for a while. It would also almost certainly screw up any
patches anyone has against the CVS HEAD, as the changes I have in mind touch
almost every aspect of every function in the source :) I also know Cord has
some (more) experimental code that he might want to check in.

If anyone is actually using the head (if you are using CVS and didn't check
out using '-r btmux_1_4-branch', or if, after you update now and install the
new binary, the version is reported as 1.5.0a0) let me know and I'll
consider making a seperate unstable branch. That, or you could refrain from
cvs updating for a while.

-- 
Thomas Wouters <th...@xs...>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

Re: [btech-discussion] Note about modifying hudinfo

[Thomas W. <th...@xs...>]

On Sun, Aug 18, 2002 at 04:03:20PM -0700, Anthony Parker wrote:

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

This is why we have major and minor version numbers in hudinfo, as well as
'extentions'. I will not allow anything to break old clients unless we
really really have to. I'd rather create a new command that displays the old
information in a new way, and keep the old command.

That said, keep in mind that the spec says specifically what to expect and
what _not_ to expect. Do _not_ rely on the number of elements in a
list-like response; the addition to 'hudinfo t' should not break any
correctly written clients, even though to be more future-correct it should
up the minor version number or add an extention flag.

Back-from-vacation-ly y'rs,

-- 
Thomas Wouters <th...@xs...>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

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
> 

[btech-discussion] Re: Note about modifying hudinfo

[Ernst B. <e.b...@xe...>]

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

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

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

Re: [btech-discussion] Note about modifying hudinfo

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

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

RE: [btech-discussion] Note about modifying hudinfo

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

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

RE: [btech-discussion] Note about modifying hudinfo

[Tuncay G. <tgo...@ma...>]

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

[btech-discussion] Note about modifying hudinfo

[Anthony P. <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

RE: [btech-discussion] Re: Hudinfo

[Tuncay G. <tgo...@ma...>]

	The aim is not to track changes on a particular map, but to
track which map it is we are on. Well, sorry my DB-design habbit kicked
in, so I gave a primary key that would be fast ie integer :-) Of course,
appending the map name to hudinfo t header line would be enough.

---
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 Manuel Klimek
> Sent: Friday, August 16, 2002 12:02 AM
> To: th...@xs...
> Cc: bte...@li...
> Subject: Re: [btech-discussion] Re: Hudinfo
>=20
>=20
> > Likewise, we can't give out 'serial numbers' for maps to=20
> indicate they
> > have changed, because of EV work and fights and all that on=20
> '30 changing
> > the map -- it would be an OOC way of gathering info. If it's
> > none-the-less a desired extention, I will accept patches=20
> for it... but
> > as an optional item, and it will be turned off for 3030 :)
>=20
> I don't know if I understood this part correctly.
> You'd need to have one serial number for every map the server
> knows (of course the server should have an own ID-Space...)
> If the map changes, this is still the same map and I have
> to explore it again (the client will for example show fields
> which are older than some timestamp in some color as an option).
> What information does this one ID per map give, other than you
> can figure out on what map you are? When does this give an
> advantage?
> Perhaps I understood you wrong... then I'm sorry ;-)
> But I would be very happy if you could clearify this to me...
>=20
> Thanks in advance,
>   Manuel
>=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=3Dsourceforge1&refcode1=3Dvs3390
> _______________________________________________
> btech-discussion mailing list
> bte...@li...
> https://lists.sourceforge.net/lists/listinfo/btech-discussion
>=20
>=20
>=20

Re: [btech-discussion] Re: Hudinfo

[Manuel K. <man...@we...>]

> Likewise, we can't give out 'serial numbers' for maps to indicate they
> have changed, because of EV work and fights and all that on '30 changing
> the map -- it would be an OOC way of gathering info. If it's
> none-the-less a desired extention, I will accept patches for it... but
> as an optional item, and it will be turned off for 3030 :)

I don't know if I understood this part correctly.
You'd need to have one serial number for every map the server
knows (of course the server should have an own ID-Space...)
If the map changes, this is still the same map and I have
to explore it again (the client will for example show fields
which are older than some timestamp in some color as an option).
What information does this one ID per map give, other than you
can figure out on what map you are? When does this give an
advantage?
Perhaps I understood you wrong... then I'm sorry ;-)
But I would be very happy if you could clearify this to me...

Thanks in advance,
  Manuel

Re: [btech-discussion] Re: Hudinfo

[Thomas W. <th...@xs...>]

On Wed, Aug 14, 2002 at 11:16:10PM +0300, Tuncay Goncuoglu wrote:

> 	I think it is a good idea indeed. However, another addition to
> hudinfo tactical command would complete this. Like:

> hudinfo map
> #HUD:KEY:MAP:R# MAPDBREF, MAPIDENTIFIER, WIDTH, HEIGHT

> (note the addition of MAPDBREF-Integer-without a #-like 5323) and

> hudinfo t <n>
> #HUD:KEY:T:S# X1,Y1,X2,Y2,MAP,MAPDBREF

We can't give out the mapdbref and use it as a map identifier because of,
for instance, simpods. You'll just end up loading the wrong map.

Likewise, we can't give out 'serial numbers' for maps to indicate they have
changed, because of EV work and fights and all that on '30 changing the map
-- it would be an OOC way of gathering info. If it's none-the-less a desired
extention, I will accept patches for it... but as an optional item, and it
will be turned off for 3030 :)

I know I haven't written a client myself, so I can't really tell you people
what to do, but I'd probably just make it a manual operation, choosing the
map.

-- 
Thomas Wouters <th...@xs...>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!