From quozl at us.netrek.org Sat Jul 5 02:26:49 2008 From: quozl at us.netrek.org (James Cameron) Date: Sat, 5 Jul 2008 17:26:49 +1000 Subject: [netrek-dev] RCD: " %T%c->%O %?%n>4%{bomb %l @ %n%!bomb%}\0" Message-ID: <20080705072649.GA13876@us.netrek.org> The help bomb RCD is phrased such that if the target planet it is called on has less than or equal to four armies, only the word "bomb" appears. It seems to me that the planet name should also appear, thus the macro would change from: " %T%c->%O %?%n>4%{bomb %l @ %n%!bomb%}\0" to: " %T%c->%O %?%n>4%{bomb %l @ %n%!bomb %l%}\0" Affects: Netrek XP 2006, netrek-client-cow, netrek-server-vanilla (INL message log and lib/tools/watchmes decode RCDs) Source: struct dmacro_list distmacro in data.c, fourth element. Does anyone have any reason why it is thje way it is? -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ From netrek at gmail.com Sat Jul 5 05:40:59 2008 From: netrek at gmail.com (Zach Uram) Date: Sat, 5 Jul 2008 06:40:59 -0400 Subject: [netrek-dev] RCD: " %T%c->%O %?%n>4%{bomb %l @ %n%!bomb%}\0" In-Reply-To: <20080705072649.GA13876@us.netrek.org> References: <20080705072649.GA13876@us.netrek.org> Message-ID: A planet cannot be bombed if it has <= 4 armies. Zach From billbalcerski at gmail.com Sat Jul 5 05:57:43 2008 From: billbalcerski at gmail.com (Bill Balcerski) Date: Sat, 5 Jul 2008 06:57:43 -0400 Subject: [netrek-dev] RCD: " %T%c->%O %?%n>4%{bomb %l @ %n%!bomb%}\0" In-Reply-To: <20080705072649.GA13876@us.netrek.org> References: <20080705072649.GA13876@us.netrek.org> Message-ID: <45ab86180807050357x4af949dahc74262cde4d20697@mail.gmail.com> I agree, I had changed this in the netrekrc.txt file but not the data struct. Relevant line from netrekrc.txt is dist.^b.bomb: %T%c->%O %?%n>4%{bomb %l @ %n%!bomb %l%} Don't remember why I didn't change data struct. Bill From list2rado at gmx.de Sat Jul 5 06:00:04 2008 From: list2rado at gmx.de (Rado S) Date: Sat, 5 Jul 2008 13:00:04 +0200 Subject: [netrek-dev] RCD: " %T%c->%O %?%n>4%{bomb %l @ %n%!bomb%}\0" In-Reply-To: <20080705072649.GA13876@us.netrek.org> References: <20080705072649.GA13876@us.netrek.org> Message-ID: <20080705110004.GA27479@sun36.math.uni-hamburg.de> =- James Cameron wrote on Sat 5.Jul'08 at 17:26:49 +1000 -= > The help bomb RCD is phrased such that if the target planet it is > called on has less than or equal to four armies, only the word > "bomb" appears. Bombing <4 makes no sense in Bronco, so if you mistakingly hit the wrong planet, it falls back to the generic "bomb" (anything, generally more). > It seems to me that the planet name should also appear, thus the > macro would change from: > " %T%c->%O %?%n>4%{bomb %l @ %n%!bomb%}\0" > to: > " %T%c->%O %?%n>4%{bomb %l @ %n%!bomb %l%}\0" bomb %l%n>4%{ @ %n%} -- ? Rado S. -- You must provide YOUR effort for your goal! EVERY effort counts: at least to show your attitude. You're responsible for ALL you do: you get what you give. From quozl at us.netrek.org Sat Jul 5 08:25:52 2008 From: quozl at us.netrek.org (James Cameron) Date: Sat, 5 Jul 2008 23:25:52 +1000 Subject: [netrek-dev] RCD: " %T%c->%O %?%n>4%{bomb %l @ %n%!bomb%}\0" In-Reply-To: <20080705110004.GA27479@sun36.math.uni-hamburg.de> References: <20080705072649.GA13876@us.netrek.org> <20080705110004.GA27479@sun36.math.uni-hamburg.de> Message-ID: <20080705132552.GC20269@us.netrek.org> A contested agri, it is at four, it is due to pop, we still want to call a bomb on it, so that someone has the job, and we get "bomb " as the message, with no planet name in the message. Or a planet recently taken, not yet scanned, calling a bomb on them also yields "bomb ". Even simpler, initial bombing run, planets that are not yet scanned, calling a bomb on them yields "bomb " as well. See my point? I already knew about the < 4 limit, thanks. -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ From list2rado at gmx.de Sat Jul 5 08:56:08 2008 From: list2rado at gmx.de (Rado S) Date: Sat, 5 Jul 2008 15:56:08 +0200 Subject: [netrek-dev] RCD: " %T%c->%O %?%n>4%{bomb %l @ %n%!bomb%}\0" In-Reply-To: <20080705132552.GC20269@us.netrek.org> References: <20080705072649.GA13876@us.netrek.org> <20080705110004.GA27479@sun36.math.uni-hamburg.de> <20080705132552.GC20269@us.netrek.org> Message-ID: <20080705135608.GF27479@sun36.math.uni-hamburg.de> =- James Cameron wrote on Sat 5.Jul'08 at 23:25:52 +1000 -= a) > A contested agri, it is at four, it is due to pop, we still want > to call a bomb on it, so that someone has the job, and we get > "bomb " as the message, with no planet name in the message. b) > Or a planet recently taken, not yet scanned, calling a bomb on > them also yields "bomb ". c) > Even simpler, initial bombing run, planets that are not yet > scanned, calling a bomb on them yields "bomb " as well. > > See my point? Yes, I've covered those cases with macros, actually 1 very complex with conditionals. When you're already at fixing defaults, you might reconsider being more verbose in those mentioned situations. Since RCD are RCD, clue can redefine to have simplistic output. "bomb Ear @ 4" is confusing when you learned that you can't bomb below 5. a) watch %t @ %n pop to bomb b) scan %t c) not sure whether this needs to be covered specially since it's obvious: bomb all you can get. But, of course, even that wouldn't hurt to be propagated more explicitely. -- ? Rado S. -- You must provide YOUR effort for your goal! EVERY effort counts: at least to show your attitude. You're responsible for ALL you do: you get what you give. From stephen.thorne at gmail.com Sat Jul 5 09:09:09 2008 From: stephen.thorne at gmail.com (Stephen Thorne) Date: Sun, 6 Jul 2008 00:09:09 +1000 Subject: [netrek-dev] Pygame client progress Message-ID: <3e8ca5c80807050709g77dfeb47vb0ed5efb653e6fa8@mail.gmail.com> G'day, I've been hacking on the pygame client, latest patches are available here: http://suqld.org.au/~stephen/netrek-client-pygame/ - also mentioned in a recent REPOSITORIES file. I have a problem on AMD64 figuring out the file descriptor of the X server. The current logic does some incredibly magical things using ctypes to dig into the X server to figure out which fd to attach to. On AMD64, the logic is out because things aren't the same size and it blows up. I have had to put a patch in to just say '4' when we figure out the fd has a number >>255. If anyone can figure out a better way of doing this, I'm all ears. I've added a patch titled "Test script for graphics display" which is aimed at facilitating more rapid development of graphics display things. It currently shows the tactical and the galactic showing two ships who move and rotate (against the laws of physics, but we can't have everything). The idea is that we can turn that script into a comprehensive list of graphics effects, so it is easier to fiddle. -- Stephen Thorne "Give me enough bandwidth and a place to sit and I will move the world." --Jonathan Lange From netrek at gmail.com Sat Jul 5 18:29:00 2008 From: netrek at gmail.com (Zach Uram) Date: Sat, 5 Jul 2008 19:29:00 -0400 Subject: [netrek-dev] RCD: " %T%c->%O %?%n>4%{bomb %l @ %n%!bomb%}\0" In-Reply-To: <20080705132552.GC20269@us.netrek.org> References: <20080705072649.GA13876@us.netrek.org> <20080705110004.GA27479@sun36.math.uni-hamburg.de> <20080705132552.GC20269@us.netrek.org> Message-ID: Ok. I guess I am more selective in how I use RCDs. I would use an RCD only on a planet that was visible and had >= 5 armies. But I can see now how others may wish to use the bombing RCD in other cases. Zach On Sat, Jul 5, 2008 at 9:25 AM, James Cameron wrote: > A contested agri, it is at four, it is due to pop, we still want to call > a bomb on it, so that someone has the job, and we get "bomb " as the > message, with no planet name in the message. > > Or a planet recently taken, not yet scanned, calling a bomb on them also > yields "bomb ". > > Even simpler, initial bombing run, planets that are not yet scanned, > calling a bomb on them yields "bomb " as well. > > See my point? > > I already knew about the < 4 limit, thanks. From quozl at us.netrek.org Sat Jul 5 19:39:18 2008 From: quozl at us.netrek.org (James Cameron) Date: Sun, 6 Jul 2008 10:39:18 +1000 Subject: [netrek-dev] RCD: " %T%c->%O %?%n>4%{bomb %l @ %n%!bomb%}\0" In-Reply-To: References: <20080705072649.GA13876@us.netrek.org> <20080705110004.GA27479@sun36.math.uni-hamburg.de> <20080705132552.GC20269@us.netrek.org> Message-ID: <20080706003918.GB4846@us.netrek.org> On Sat, Jul 05, 2008 at 07:29:00PM -0400, Zach Uram wrote: > Ok. I guess I am more selective in how I use RCDs. I would use an RCD > only on a planet that was visible and had >= 5 armies. But I can see > now how others may wish to use the bombing RCD in other cases. Your use was changed by the RCD behaviour. I was hoping you'd realise that. It was while adding these to the Pygame client that I cross-checked them. -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ From quozl at us.netrek.org Sat Jul 5 23:05:39 2008 From: quozl at us.netrek.org (James Cameron) Date: Sun, 6 Jul 2008 14:05:39 +1000 Subject: [netrek-dev] Pygame client progress In-Reply-To: <3e8ca5c80807050709g77dfeb47vb0ed5efb653e6fa8@mail.gmail.com> References: <3e8ca5c80807050709g77dfeb47vb0ed5efb653e6fa8@mail.gmail.com> Message-ID: <20080706040539.GC4846@us.netrek.org> Mmm, nice. Be able to test for regressions in display performance. Thanks. In changes just pushed ... Add experimental support for tactical halos, which are arcs of circles drawn near the edge of tactical, to express distance and bearing to off-screen objects such as ships. - not drawn in red alert, - drawn every ten updates, so lag reality, - dark green for our planets, - light green for our team players, - red for non-team (enemy) players, - thicker for players with kills. On Sun, Jul 06, 2008 at 12:09:09AM +1000, Stephen Thorne wrote: > I have a problem on AMD64 figuring out the file descriptor of the X > server. The current logic does some incredibly magical things using > ctypes to dig into the X server to figure out which fd to attach to. I think it is digging into the X library, actually, not the server. The mysterious code came from the One Laptop Per Child project, where AMD64 was not a consideration. Pygame rests on top of SDL, and SDL rests on top of Xlib. Xlib manages the UNIX socket or TCP socket connection to the X server. Here is a guess as to what it does. I think it is looking into the _XDisplay struct as defined by Xlib.h, which contains two pointers then an int fd. typedef struct _XDisplay { XExtData *ext_data; /* hook for extension to hang data */ struct _XPrivate *private1; int fd; /* Network socket. */ ... } Therefore on AMD64 that last "n+8" should be "n+16" since the two members of the struct immediately before the fd are pointers. Working backwards ... here is where it gets doubtful ... I don't know what str(pygame.display.get_wm_info()['display'])[23:-1] is other than it looks like an address in hex, presumably of something that points to something that points to the _XDisplay struct. Many people have asked pygame to expose their X socket file descriptor, and that they haven't suggests it might be an SDL limitation. -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ From darius at dons.net.au Sun Jul 6 05:24:36 2008 From: darius at dons.net.au (Daniel O'Connor) Date: Sun, 6 Jul 2008 19:54:36 +0930 Subject: [netrek-dev] Pygame client progress In-Reply-To: <20080706040539.GC4846@us.netrek.org> References: <3e8ca5c80807050709g77dfeb47vb0ed5efb653e6fa8@mail.gmail.com> <20080706040539.GC4846@us.netrek.org> Message-ID: <200807061954.37556.darius@dons.net.au> On Sun, 6 Jul 2008, James Cameron wrote: > Mmm, nice. Be able to test for regressions in display performance. > Thanks. > > In changes just pushed ... > > Add experimental support for tactical halos, which are arcs of > circles drawn near the edge of tactical, to express distance and > bearing to off-screen objects such as ships. > > - not drawn in red alert, > - drawn every ten updates, so lag reality, > - dark green for our planets, > - light green for our team players, > - red for non-team (enemy) players, > - thicker for players with kills. > > On Sun, Jul 06, 2008 at 12:09:09AM +1000, Stephen Thorne wrote: > > I have a problem on AMD64 figuring out the file descriptor of the X > > server. The current logic does some incredibly magical things using > > ctypes to dig into the X server to figure out which fd to attach > > to. > > I think it is digging into the X library, actually, not the server. > > The mysterious code came from the One Laptop Per Child project, where > AMD64 was not a consideration. > > Pygame rests on top of SDL, and SDL rests on top of Xlib. Xlib > manages the UNIX socket or TCP socket connection to the X server. > > Here is a guess as to what it does. I think it is looking into the > _XDisplay struct as defined by Xlib.h, which contains two pointers > then an int fd. > > typedef struct _XDisplay > { > XExtData *ext_data; /* hook for extension to hang data */ > struct _XPrivate *private1; > int fd; /* Network socket. */ > ... } > > Therefore on AMD64 that last "n+8" should be "n+16" since the two > members of the struct immediately before the fd are pointers. FWIW you can tell ctypes about structures and so it should then work out the sizes itself (say specify the pointers as void *) ie http://www.python.org/doc/current/lib/ctypes-structures-unions.html > Many people have asked pygame to expose their X socket file > descriptor, and that they haven't suggests it might be an SDL > limitation. Pesky abstractions ;) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: This is a digitally signed message part. Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20080706/5b29384a/attachment.pgp From stephen.thorne at gmail.com Sun Jul 6 06:40:17 2008 From: stephen.thorne at gmail.com (Stephen Thorne) Date: Sun, 6 Jul 2008 21:40:17 +1000 Subject: [netrek-dev] Pygame client progress In-Reply-To: <200807061954.37556.darius@dons.net.au> References: <3e8ca5c80807050709g77dfeb47vb0ed5efb653e6fa8@mail.gmail.com> <20080706040539.GC4846@us.netrek.org> <200807061954.37556.darius@dons.net.au> Message-ID: <3e8ca5c80807060440p1a94a113hd0e8dd0fc5c20f33@mail.gmail.com> On Sun, Jul 6, 2008 at 8:24 PM, Daniel O'Connor wrote: >> Many people have asked pygame to expose their X socket file >> descriptor, and that they haven't suggests it might be an SDL >> limitation. > > Pesky abstractions ;) I've actually been told by a pygame developer that "no, you're doing it wrong" when presented with the use-case of wanting to do a select() on the X fd and the network at the same time. bizarre point of view if you ask me. -- Stephen Thorne "Give me enough bandwidth and a place to sit and I will move the world." --Jonathan Lange From darius at dons.net.au Sun Jul 6 07:37:01 2008 From: darius at dons.net.au (Daniel O'Connor) Date: Sun, 6 Jul 2008 22:07:01 +0930 Subject: [netrek-dev] Pygame client progress In-Reply-To: <3e8ca5c80807060440p1a94a113hd0e8dd0fc5c20f33@mail.gmail.com> References: <3e8ca5c80807050709g77dfeb47vb0ed5efb653e6fa8@mail.gmail.com> <200807061954.37556.darius@dons.net.au> <3e8ca5c80807060440p1a94a113hd0e8dd0fc5c20f33@mail.gmail.com> Message-ID: <200807062207.08573.darius@dons.net.au> On Sun, 6 Jul 2008, Stephen Thorne wrote: > On Sun, Jul 6, 2008 at 8:24 PM, Daniel O'Connor wrote: > >> Many people have asked pygame to expose their X socket file > >> descriptor, and that they haven't suggests it might be an SDL > >> limitation. > > > > Pesky abstractions ;) > > I've actually been told by a pygame developer that "no, you're doing > it wrong" when presented with the use-case of wanting to do a > select() on the X fd and the network at the same time. > > bizarre point of view if you ask me. I imagine the correct usage is probably something involving threads or some SDL based waiting mechanism. Assuming you're using an X server on a POSIX platform does somewhat defeat the point of using pygame/SDL/etc in the first place.. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: This is a digitally signed message part. Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20080706/1763fa55/attachment.pgp From niclas at acc.umu.se Mon Jul 7 05:02:52 2008 From: niclas at acc.umu.se (Niclas Fredriksson) Date: Mon, 7 Jul 2008 12:02:52 +0200 (MEST) Subject: [netrek-dev] RCD: " %T%c->%O %?%n>4%{bomb %l @ %n%!bomb%}\0" In-Reply-To: References: <20080705072649.GA13876@us.netrek.org> Message-ID: On Mon, 7 Jul 2008, Niclas Fredriksson wrote: > It's a good change. There is no good reason to keep it was it is (other > than possibly "but it's always been like that!" and while I often > advocate that stand point, it's not valid in this case). That being said, many of us have used this macro to send a generic "guys we need to bomb!" message by hitting ctrl-b on a not yet orbited planet, but I guess we need to move our lazy right hand to the keyboard and type "bomb!" now instead (or do the ultra lazy thing and use mac.B.T: BOMB!, heh). -- Niclas From niclas at acc.umu.se Mon Jul 7 05:02:52 2008 From: niclas at acc.umu.se (Niclas Fredriksson) Date: Mon, 7 Jul 2008 12:02:52 +0200 (MEST) Subject: [netrek-dev] RCD: " %T%c->%O %?%n>4%{bomb %l @ %n%!bomb%}\0" In-Reply-To: References: <20080705072649.GA13876@us.netrek.org> Message-ID: On Mon, 7 Jul 2008, Niclas Fredriksson wrote: > It's a good change. There is no good reason to keep it was it is (other > than possibly "but it's always been like that!" and while I often > advocate that stand point, it's not valid in this case). That being said, many of us have used this macro to send a generic "guys we need to bomb!" message by hitting ctrl-b on a not yet orbited planet, but I guess we need to move our lazy right hand to the keyboard and type "bomb!" now instead (or do the ultra lazy thing and use mac.B.T: BOMB!, heh). -- Niclas From niclas at acc.umu.se Mon Jul 7 04:59:55 2008 From: niclas at acc.umu.se (Niclas Fredriksson) Date: Mon, 7 Jul 2008 11:59:55 +0200 (MEST) Subject: [netrek-dev] RCD: " %T%c->%O %?%n>4%{bomb %l @ %n%!bomb%}\0" In-Reply-To: <20080705072649.GA13876@us.netrek.org> References: <20080705072649.GA13876@us.netrek.org> Message-ID: On Sat, 5 Jul 2008, James Cameron wrote: > The help bomb RCD is phrased such that if the target planet it is called > on has less than or equal to four armies, only the word "bomb" appears. > > It seems to me that the planet name should also appear, thus the macro > would change from: > > " %T%c->%O %?%n>4%{bomb %l @ %n%!bomb%}\0" > > to: > > " %T%c->%O %?%n>4%{bomb %l @ %n%!bomb %l%}\0" > > Affects: Netrek XP 2006, netrek-client-cow, netrek-server-vanilla (INL > message log and lib/tools/watchmes decode RCDs) > > Source: struct dmacro_list distmacro in data.c, fourth element. > > Does anyone have any reason why it is thje way it is? It's a good change. There is no good reason to keep it was it is (other than possibly "but it's always been like that!" and while I often advocate that stand point, it's not valid in this case). I read the whole thread. If you use the macro on a non-agri @ 1 it's not the macros fault that you get "bomb ear @ 1". -- Niclas From niclas at acc.umu.se Mon Jul 7 04:59:55 2008 From: niclas at acc.umu.se (Niclas Fredriksson) Date: Mon, 7 Jul 2008 11:59:55 +0200 (MEST) Subject: [netrek-dev] RCD: " %T%c->%O %?%n>4%{bomb %l @ %n%!bomb%}\0" In-Reply-To: <20080705072649.GA13876@us.netrek.org> References: <20080705072649.GA13876@us.netrek.org> Message-ID: On Sat, 5 Jul 2008, James Cameron wrote: > The help bomb RCD is phrased such that if the target planet it is called > on has less than or equal to four armies, only the word "bomb" appears. > > It seems to me that the planet name should also appear, thus the macro > would change from: > > " %T%c->%O %?%n>4%{bomb %l @ %n%!bomb%}\0" > > to: > > " %T%c->%O %?%n>4%{bomb %l @ %n%!bomb %l%}\0" > > Affects: Netrek XP 2006, netrek-client-cow, netrek-server-vanilla (INL > message log and lib/tools/watchmes decode RCDs) > > Source: struct dmacro_list distmacro in data.c, fourth element. > > Does anyone have any reason why it is thje way it is? It's a good change. There is no good reason to keep it was it is (other than possibly "but it's always been like that!" and while I often advocate that stand point, it's not valid in this case). I read the whole thread. If you use the macro on a non-agri @ 1 it's not the macros fault that you get "bomb ear @ 1". -- Niclas From quozl at us.netrek.org Mon Jul 7 20:42:44 2008 From: quozl at us.netrek.org (James Cameron) Date: Tue, 8 Jul 2008 11:42:44 +1000 Subject: [netrek-dev] RCD: " %T%c->%O %?%n>4%{bomb %l @ %n%!bomb%}\0" In-Reply-To: <45ab86180807050357x4af949dahc74262cde4d20697@mail.gmail.com> References: <20080705072649.GA13876@us.netrek.org> <45ab86180807050357x4af949dahc74262cde4d20697@mail.gmail.com> Message-ID: <20080708014243.GC11072@us.netrek.org> Change made. -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ --- old-netrek-server/Vanilla/ntserv/data.c 2008-07-08 11:40:35.000000000 +1000 +++ new-netrek-server/Vanilla/ntserv/data.c 2008-07-08 11:40:35.000000000 +1000 @@ -333,7 +333,7 @@ { 'X', "no zero", "this should never get looked at" }, { 't', "taking", " %T%c->%O (%S) Carrying %a to %l%?%n>-1%{ @ %n%}\0"}, { 'o', "ogg", " %T%c->%O Help Ogg %p at %l\0" }, - { 'b', "bomb", " %T%c->%O %?%n>4%{bomb %l @ %n%!bomb%}\0"}, + { 'b', "bomb", " %T%c->%O %?%n>4%{bomb %l @ %n%!bomb %l%}\0"}, { 'c', "space_control", " %T%c->%O Help Control at %L\0" }, { '1', "save_planet", " %T%c->%O Emergency at %L!!!!\0" }, { '2', "base_ogg", " %T%c->%O Sync with --]> %g <[-- OGG ogg OGG base!!\0" }, --- old-netrek-client-cow/data.c 2008-07-08 11:39:31.000000000 +1000 +++ new-netrek-client-cow/data.c 2008-07-08 11:39:31.000000000 +1000 @@ -501,7 +501,7 @@ /* ^o */ {'\xcf', "ogg", " %T%c->%O Help Ogg %p at %l\0"}, /* ^b */ - {'\xc2', "bomb", " %T%c->%O %?%n>4%{bomb %l @ %n%!bomb%}\0"}, + {'\xc2', "bomb", " %T%c->%O %?%n>4%{bomb %l @ %n%!bomb %l%}\0"}, /* ^c */ {'\xc3', "space_control", " %T%c->%O Help Control at %L\0"}, /* ^1 */ RCS file: /cvsroot/netrek/client/netrekxp/src/data.c,v retrieving revision 1.110 diff -u -r1.110 data.c --- data.c 19 Apr 2008 20:03:00 -0000 1.110 +++ data.c 8 Jul 2008 01:39:22 -0000 @@ -552,7 +552,7 @@ /* ^o */ {(unsigned char) ('\xcf'), "ogg", " %T%c->%O Help Ogg %p at %l\0"}, /* ^b */ - {(unsigned char) ('\xc2'), "bomb", " %T%c->%O %?%n>4%{bomb %l @ %n%!bomb%}\0"}, + {(unsigned char) ('\xc2'), "bomb", " %T%c->%O %?%n>4%{bomb %l @ %n%!bomb %l%}\0"}, /* ^c */ {(unsigned char) ('\xc3'), "space_control", " %T%c->%O Help Control at %L\0"}, /* ^1 */ From quozl at us.netrek.org Mon Jul 7 23:50:07 2008 From: quozl at us.netrek.org (James Cameron) Date: Tue, 8 Jul 2008 14:50:07 +1000 Subject: [netrek-dev] Metaserver 3522 Message-ID: <20080708045007.GA17712@us.netrek.org> Does anybody seriously need this any more? It is causing support issues, from someone who still uses it. It also reveals IP addresses of some players without having to pass the login within a client. It reveals the entire player list of a server despite any server bans on the person running the query. -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ From carlos at jpl.nasa.gov Tue Jul 8 14:41:32 2008 From: carlos at jpl.nasa.gov (Carlos Y. Villalpando) Date: Tue, 8 Jul 2008 12:41:32 -0700 Subject: [netrek-dev] Metaserver 3522 In-Reply-To: <20080708045007.GA17712@us.netrek.org> References: <20080708045007.GA17712@us.netrek.org> Message-ID: <20080708194132.GA3480@carlos-desktop> Quoting James Cameron : > Does anybody seriously need this any more? Whenever I get the gumption to play, I use it to check to see if there is someone worth playing with. > It is causing support issues, from someone who still uses it. What is the issue? There seems to be a duplication between {home,away}.clue.netrek.org, but that's because it's the same server reporting as two separate servers. Oh, and the fact that it doesn't have the same dead server hiding logic applied to it. > It also reveals IP addresses of some players without having to pass the > login within a client. That was the whole point of 3522, no? > It reveals the entire player list of a server despite any server > bans on the person running the query. Why is that a problem? --Carlos V. From quozl at us.netrek.org Thu Jul 10 01:13:19 2008 From: quozl at us.netrek.org (James Cameron) Date: Thu, 10 Jul 2008 16:13:19 +1000 Subject: [netrek-dev] [PATCH] netrek-client-cow keyboard event handling delay Message-ID: <20080710061319.GA20593@us.netrek.org> In case anyone sees this one ... two weeks ago an upgrade on my system made Netrek very unresponsive. Eventually it was tracked down to keyboard and mouse event handling between the X libraries and the client. It should have no impact on the Windows client, totally different event architecture. Thu Jul 10 16:04:55 EST 2008 quozl at us.netrek.org * input, fix for Debian Lenny Xlib changes Fix delayed response to keyboard events. Fixes a regression introduced by an upgrade of Debian GNU/Linux Lenny Xlib and Xcb layers. The symptom was that keyboard events would be delayed, they would be buffered by Xlib before our code would handle them. The cause was the use of select(2) and the handling of the X event queue by the client. The change is to allow Xlib a chance to read the X socket before asking Xlib for the events. Then, all events are processed, before proceeding. diff -rN -u old-netrek-client-cow/input.c new-netrek-client-cow/input.c --- old-netrek-client-cow/input.c 2008-07-10 16:09:01.000000000 +1000 +++ new-netrek-client-cow/input.c 2008-07-10 16:09:01.000000000 +1000 @@ -755,16 +755,21 @@ #ifndef THREADED #ifndef HAVE_WIN32 - if (FD_ISSET(xsock, &readfds)) + /* keyboard, mouse, and expose events from the X server + cause the X socket to be readable, so we must direct Xlib + to read them (W_EventsQueuedCk), then we process them. */ + if (FD_ISSET(xsock, &readfds)) { + while (W_EventsQueuedCk()) + process_event(); + doflush = 1; + } #else if (W_EventsPending()) -#endif /* !HAVE_WIN32 */ - { process_event(); - /* NOTE: we're no longer calling XPending(), need this */ doflush = 1; } +#endif /* !HAVE_WIN32 */ #endif /* !THREADED */ if (FD_ISSET(sock, &readfds) || -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ From quozl at us.netrek.org Fri Jul 11 05:45:13 2008 From: quozl at us.netrek.org (James Cameron) Date: Fri, 11 Jul 2008 20:45:13 +1000 Subject: [netrek-dev] [PATCH] SP_GENERIC_32 version 'b' support Message-ID: <20080711104513.GA28206@us.netrek.org> For review and comment. The purpose of this patch is to: 1. fix the flaw in SP_GENERIC_32 caused by not byte swapping the values, in a way that does not break existing clients that began to use the packet, by using the next version number 'b', and by allowing the client to state which version it desires, 2. add Bronco t-mode and clue game support features to the packet, to allow development of client side tools without falling back on message parsing. The new values in the packet include: a. the value of status->gameup, so that server status flags can be displayed, b. the team numbers of the two teams involved in t-mode, c. the duration of t-mode so far, (hitherto clients have had to calculate duration based on when they observed t-mode to begin), d. the remaining time in t-mode for an INL or clue game, (hitherto only available by parsing messages to ALL or by sending TIME command), e. the starbase reconstruction time, (hitherto ... SBTIME), f. the team surrender time, for whatever team is considering surrender, Patch below. Fri Jul 11 20:38:10 EST 2008 quozl at us.netrek.org * SP_GENERIC_32 version 'b' packet support diff -rN -u old-netrek-server/Vanilla/docs/sample_features new-netrek-server/Vanilla/docs/sample_features --- old-netrek-server/Vanilla/docs/sample_features 2008-07-11 20:38:48.000000000 +1000 +++ new-netrek-server/Vanilla/docs/sample_features 2008-07-11 20:38:48.000000000 +1000 @@ -63,8 +63,8 @@ LITE_SOUNDS C ON # ship stat. packets SHIP_CAP S ON -# generic packets -SP_GENERIC_32 S ON +# generic packets (plus packet version number) +SP_GENERIC_32 S ON 2 # Despite using short packets, show full direction resolution for # ships. The same information for players is already included in the # original packet format. When a client requests this feature, the diff -rN -u old-netrek-server/Vanilla/include/packets.h new-netrek-server/Vanilla/include/packets.h --- old-netrek-server/Vanilla/include/packets.h 2008-07-11 20:38:48.000000000 +1000 +++ new-netrek-server/Vanilla/include/packets.h 2008-07-11 20:38:48.000000000 +1000 @@ -998,26 +998,57 @@ u_short s_bitmap; }; -struct generic_32_spacket { /* SP_GENERIC_32 py-struct "!bbhh26x" #32 */ - char type; - char version; /* alphabetic */ - short repair_time; /* server estimate of repair time in seconds */ - short pl_orbit; /* what planet player orbiting, -1 if none */ - char pad1[26]; /* TODO: consider using a union */ +struct generic_32_spacket { + char type; + char pad[31]; }; -#define GENERIC_32_VERSION 'a' #define GENERIC_32_LENGTH 32 #define COST_GENERIC_32 (F_sp_generic_32 ? GENERIC_32_LENGTH : 0) +struct generic_32_spacket_a { /* SP_GENERIC_32 py-struct "b1sHH26x" #32 */ + char type; + char version; /* alphabetic, 0x60 + version */ + u_short repair_time; /* server estimate of repair time in seconds */ + u_short pl_orbit; /* what planet player orbiting, -1 if none */ + char pad1[26]; + /* NOTE: this version didn't use network byte order for the shorts */ +}; +#define GENERIC_32_VERSION_A 1 +struct generic_32_spacket_b { /* SP_GENERIC_32 py-struct "!b1sHbHBBsBsBB18x" #32 */ + char type; + char version; /* alphabetic, 0x60 + version */ + u_short repair_time; /* server estimate of repair time, seconds */ + char pl_orbit; /* what planet player orbiting, -1 if none */ + u_short gameup; /* server status flags */ + u_char tournament_teams; /* what teams are involved */ + u_char tournament_age; /* duration of t-mode so far */ + char tournament_age_units; /* units for above, see s2du */ + u_char tournament_remain; /* remaining INL game time */ + char tournament_remain_units; /* units for above, see s2du */ + u_char starbase_remain; /* starbase reconstruction, mins */ + u_char team_remain; /* team surrender time, seconds */ + char pad1[18]; +} __attribute__ ((packed)); +#define GENERIC_32_VERSION_B 2 +#define GENERIC_32_VERSION GENERIC_32_VERSION_B /* default */ + +/* SP_GENERIC_32 versioning instructions: + + we start with version 'a', and each time a structure is changed + increment the version and reduce the pad size, keeping the packet + the same size ... + + client is entitled to trust fields in struct that were defined at a + particular version ... + + client is to send CP_FEATURE with SP_GENERIC_32 value 1 for version + 'a', value 2 for version 'b', etc ... + + server is to reply with SP_FEATURE with SP_GENERIC_32 value set to + the maximum version it supports (not the version requested by the + client), ... -/* versioning instructions: we start with version 'a', and each time a - field is added increment the version and reduce the pad size, - keeping the packet the same size ... client is entitled to trust - fields in struct that were defined at a particular version. */ - -/* - packet.type = SP_GENERIC_32; - packet.version = GENERIC_32_VERSION; - if (sizeof(struct generic_32_spacket) != GENERIC_32_LENGTH) abort(); + server is to send SP_GENERIC_32 packets of the highest version it + knows about, but no higher than the version the client asks for. */ struct flags_all_spacket { diff -rN -u old-netrek-server/Vanilla/ntserv/genspkt.c new-netrek-server/Vanilla/ntserv/genspkt.c --- old-netrek-server/Vanilla/ntserv/genspkt.c 2008-07-11 20:38:48.000000000 +1000 +++ new-netrek-server/Vanilla/ntserv/genspkt.c 2008-07-11 20:38:48.000000000 +1000 @@ -2365,7 +2365,15 @@ clientSelfShip.damage = -1; clientSelfShort.pnum = -1; - clientGeneric32.repair_time = -1; + clientGeneric32.type = 0; + if (sizeof(struct generic_32_spacket_a) != GENERIC_32_LENGTH) { + fprintf(stderr, "SP_GENERIC_32 size a wrong at %d bytes\n", + sizeof(struct generic_32_spacket_a)); + } + if (sizeof(struct generic_32_spacket_b) != GENERIC_32_LENGTH) { + fprintf(stderr, "SP_GENERIC_32 size b wrong at %d bytes\n", + sizeof(struct generic_32_spacket_b)); + } } /* Routine called by forceUpdate to clear local packet info, and force @@ -2652,27 +2660,77 @@ sendClientPacket((CVOID) &maskPacket); } +static struct generic_32_spacket_a * +sendGeneric32PacketA(struct player *pl, struct generic_32_spacket_a *ga) +{ + ga->type = SP_GENERIC_32; + ga->version = 'a'; + /*! we did not use network byte order for these two fields */ + ga->repair_time = pl->p_repair_time; + ga->pl_orbit = pl->p_flags & PFORBIT ? pl->p_planet : -1; + return ga; +} + +static struct generic_32_spacket_b * +sendGeneric32PacketB(struct player *pl, struct generic_32_spacket_b *gb) +{ + int v, t; + + gb->type = SP_GENERIC_32; + gb->version = 'b'; + gb->repair_time = ntohs(pl->p_repair_time); + gb->pl_orbit = pl->p_flags & PFORBIT ? pl->p_planet : -1; + + gb->gameup = ntohs(status->gameup & 0xffff); + + gb->tournament_teams = ((context->quorum[1] << 4) & 0xf0) | + (context->quorum[0] & 0xf); + + v = (context->frame - context->frame_tourn_start) / fps; + s2du(v, &gb->tournament_age, &gb->tournament_age_units); + + v = context->inl_remaining / fps; + s2du(v, &gb->tournament_remain, &gb->tournament_remain_units); + + v = teams[pl->p_team].te_turns; + if (v < 0) v = 0; + if (v > 255) v = 255; + gb->starbase_remain = v; + + for (t=0;((t<=MAXTEAM)&&(teams[t].te_surrender==0));t++); + if (t > MAXTEAM) { + gb->team_remain = 0; /* no one is considering surrender now */ + } else { + v = teams[t].te_surrender * 60 + + ((context->frame - teams[t].te_surrender_frame) / fps); + gb->team_remain = (v > 255) ? 255 : v; + } + + return gb; +} + void sendGeneric32Packet(void) { - struct generic_32_spacket gp; + struct generic_32_spacket g, *gp; int len = GENERIC_32_LENGTH; - struct player *pl; if (!F_sp_generic_32) return; + memset(&g, 0, len); - pl = my(); - memset(&gp, 0, len); - gp.type = SP_GENERIC_32; - gp.version = GENERIC_32_VERSION; - /*! @bug not using network byte order for these two fields. - may need to do this in next version of packet */ - gp.repair_time = pl->p_repair_time; - gp.pl_orbit = pl->p_flags & PFORBIT ? pl->p_planet : -1; - - if (memcmp(&clientGeneric32, &gp, len) != 0) { - memcpy(&clientGeneric32, &gp, len); - sendClientPacket(&gp); + gp = NULL; + if (A_sp_generic_32 == GENERIC_32_VERSION_A || + A_sp_generic_32 == 0) + gp = (struct generic_32_spacket *) + sendGeneric32PacketA(my(), (struct generic_32_spacket_a *)&g); + if (A_sp_generic_32 == GENERIC_32_VERSION_B) + gp = (struct generic_32_spacket *) + sendGeneric32PacketB(my(), (struct generic_32_spacket_b *)&g); + if (gp == NULL) return; + + if (memcmp(&clientGeneric32, gp, len) != 0) { + memcpy(&clientGeneric32, gp, len); + sendClientPacket(gp); } } -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ From niclas at acc.umu.se Fri Jul 11 05:58:07 2008 From: niclas at acc.umu.se (Niclas Fredriksson) Date: Fri, 11 Jul 2008 12:58:07 +0200 (MEST) Subject: [netrek-dev] Metaserver 3522 In-Reply-To: <20080708045007.GA17712@us.netrek.org> References: <20080708045007.GA17712@us.netrek.org> Message-ID: On Tue, 8 Jul 2008, James Cameron wrote: > Does anybody seriously need this any more? It is causing support > issues, from someone who still uses it. I haven't used it in years since we only get games on one server these days, so it's faster for me to connect to the server and look at the player list. But I still think it's a nice thing to have. What are the support issues? Are support issues in general reigstered somewhere for the public (in this case me) to review? -- Niclas From quozl at us.netrek.org Fri Jul 11 06:29:55 2008 From: quozl at us.netrek.org (James Cameron) Date: Fri, 11 Jul 2008 21:29:55 +1000 Subject: [netrek-dev] Metaserver 3522 In-Reply-To: References: <20080708045007.GA17712@us.netrek.org> Message-ID: <20080711112955.GA29428@us.netrek.org> On Fri, Jul 11, 2008 at 12:58:07PM +0200, Niclas Fredriksson wrote: > I haven't used it in years since we only get games on one server these > days, so it's faster for me to connect to the server and look at the > player list. But I still think it's a nice thing to have. Ok. Thanks. > What are the support issues? Every few years someone asks about it and I have to learn again what it does. Someone asked the other day. I thought if it wasn't really needed I could just turn it off. > Are support issues in general reigstered somewhere for the public (in this > case me) to review? No, just private or IRC communications. -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ From quozl at us.netrek.org Wed Jul 16 00:16:10 2008 From: quozl at us.netrek.org (James Cameron) Date: Wed, 16 Jul 2008 15:16:10 +1000 Subject: [netrek-dev] p_updates and torp requests, 50 FPS impact Message-ID: <20080716051610.GA9873@us.netrek.org> G'day, Just writing up the COW changes prior to release announcement, and I'm wondering if anyone else has noticed that a 50 FPS server allows more torps to be fired in a burst than a 10 FPS server. udplayers() in daemon updates p_updates once per frame. ntorp() in torp.c drops torp requests if they have arrived within the same p_updates frame. I'd like to change this check to bring back the older behaviour. Has anyone noticed the effect? -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ From quozl at us.netrek.org Wed Jul 16 00:34:03 2008 From: quozl at us.netrek.org (James Cameron) Date: Wed, 16 Jul 2008 15:34:03 +1000 Subject: [netrek-dev] netrek-client-cow-3.2.4 released Message-ID: <20080716053403.GA7982@us.netrek.org> netrek-client-cow 3.2.4 was released, containing several fixes for delayed keyboard and mouse response on modern Linux systems, mature full screen support, and some immature INL clue game state support using the new SP_GENERIC_32 version 'b' packet. http://quozl.linux.org.au/netrek/ 82da7fb629930b9396e9a71a9e215c63 netrek-client-cow-3.2.4.tar.gz Summary of user changes: - play, fixed inability to fire a stream of eight torps when in TCP mode, which was caused by a combination of packet amalgamation due to the TCP/IP Nagle algorithm, and the server's decision to prevent more than one torp from being fired per update. - play, fixed a delay in responding to keyboard and mouse events ... which was caused by a regression on Debian GNU/Linux Lenny where the latest Xlib and XCB more closely adhered to the manual pages for the X event queue functions. - clue play, add SP_GENERIC_32 version 'b' support, client now requests the packets from the server, and will display mid-galactic messages relating to INL mode games, including pregame, pause, and time left in game. - messaging, fixed bombing RCD to show planet name even when target planet is not scanned, - metaserver list window, changed default metaserver mode to UDP, avoid displaying metaserver list until at least one reply is received, default the list size to about 6 entries, and add keyboard keys for refresh and quit, - graphics, menu styles adjusted to remove thick white lines, - networking, banned during login or loss of connection during play, added messages corresponding to the reason code in the SP_BADVERSION packet, - networking, removed the reconnect after connection loss feature, since (a) the server side has removed it, and (b) most connection losses these days are not recoverable in this way. - graphics, finished full screen and camera support, fixed failure to restore original resolution in many cases, added a warning window message to acknowledge resolution change key ("), - login, fixed delay in and lack of "Seconds to go" on login screen caused by redraw, fixed delayed handling of keyboard events during login screen, removed login screen warning "Keep your mouse in this window to type" since the code now accepts keystrokes no matter what window they appear to be typed into, - usage, changed most stdout messages to be stderr, and lowercase, and changed from the term "ghostbusted" to "disconnected" or "server connection lost", to ease comprehension, Summary of technical changes: - internal, fixed many compilation warnings, removed many redundant CVS revision logs from file headers, still more to go. -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20080716/58e3b58b/attachment.pgp From billbalcerski at gmail.com Wed Jul 16 08:07:55 2008 From: billbalcerski at gmail.com (Bill Balcerski) Date: Wed, 16 Jul 2008 09:07:55 -0400 Subject: [netrek-dev] p_updates and torp requests, 50 FPS impact In-Reply-To: <20080716051610.GA9873@us.netrek.org> References: <20080716051610.GA9873@us.netrek.org> Message-ID: <45ab86180807160607ge43eab1x59eb302a93a3abce@mail.gmail.com> From mark at mark.mielke.cc Wed Jul 16 08:44:37 2008 From: mark at mark.mielke.cc (Mark Mielke) Date: Wed, 16 Jul 2008 09:44:37 -0400 Subject: [netrek-dev] p_updates and torp requests, 50 FPS impact In-Reply-To: <45ab86180807160607ge43eab1x59eb302a93a3abce@mail.gmail.com> References: <20080716051610.GA9873@us.netrek.org> <45ab86180807160607ge43eab1x59eb302a93a3abce@mail.gmail.com> Message-ID: <487DFB45.2070804@mark.mielke.cc> Bill Balcerski wrote: > >From playing on 50 FPS, it does feel like you can shoot torps faster > via the "hold down torp key and move mouse" technique, but for the > traditional 1 click/keypress per torp method it's really quite hard to > notice due to limitation on my human reflexes. Server already limits > to 1 torp request per server update (guess this was anti-borg code?). > I don't mind changing the server to limit it to 10 torps/second, as > long as it isn't going to make players feel they are "losing" torp > request packets because the server is ignoring them because they can > click too fast. > > It would also be nice if pickled was at more than 10 updates/second. > Maybe round up to 11+ per second - that way there can be no complaint compared to previous behaviour, and I really doubt a person can honestly hit the same key 11+ times per second. :-) So, for 50 FPS, maybe only allow torps every change to update >> 2 which would alow for 12.5 torps per second? Cheers, mark -- Mark Mielke From quozl at us.netrek.org Wed Jul 16 23:50:12 2008 From: quozl at us.netrek.org (James Cameron) Date: Thu, 17 Jul 2008 14:50:12 +1000 Subject: [netrek-dev] p_updates and torp requests, 50 FPS impact In-Reply-To: <487DFB45.2070804@mark.mielke.cc> References: <20080716051610.GA9873@us.netrek.org> <45ab86180807160607ge43eab1x59eb302a93a3abce@mail.gmail.com> <487DFB45.2070804@mark.mielke.cc> Message-ID: <20080717045011.GC9935@us.netrek.org> So how about this patch. Apart from some trivial comment cleanups, it attempts to restore the 10 fps behaviour. I've done some testing with a modified Python client that sends eight CP_TORP packets for every mouse click. On a local server, without this patch, I got just one torp. On continuum, I got two. On pickled, I got one. Continuum is on 50 fps. Pickled is on 10 fps. The patch also changes the static variable to match the same bit length as the p_updates variable, and notes that it introduces a bug that will stop a ship firing torps after 497 days alive at 50 fps ... which is 2^31 frames. --- old-netrek-server/Vanilla/ntserv/torp.c 2008-07-17 14:44:43.000000000 +1000 +++ new-netrek-server/Vanilla/ntserv/torp.c 2008-07-17 14:44:43.000000000 +1000 @@ -51,15 +51,16 @@ */ void ntorp(u_char course, int attributes) { - static LONG last_torp_fired_update = 0; + static int last_torp_fired_update = 0; struct torp *k; if (status->gameup & GU_CONQUER) return; /* * Prevent player from firing more than one torp per update. */ - if (me->p_updates == last_torp_fired_update) + if (me->p_updates < (last_torp_fired_update + (fps / 10))) return; + /*! @bug ship may stop firing torps after 497 days alive at 50 fps */ if (me->p_flags & PFWEP) { new_warning(25, "Torpedo launch tubes have exceeded maximum safe temperature!"); @@ -138,8 +139,7 @@ me->p_fuel -= myship->s_torpcost; me->p_wtemp += (myship->s_torpcost / 10) - 10; /* Heat weapons */ - /* - * Initialize torp: */ + /* initialize torp */ k->t_status = TMOVE; k->t_type = TPHOTON; k->t_attribute = attributes; @@ -164,13 +164,9 @@ #endif #ifdef LTD_STATS - - /* At this point, a torpedo was fired */ if (status->tourn) { ltd_update_torp_fired(me); } - #endif - } -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ From netrek at gmail.com Thu Jul 17 16:34:25 2008 From: netrek at gmail.com (Zach Uram) Date: Thu, 17 Jul 2008 17:34:25 -0400 Subject: [netrek-dev] bronco t problem Message-ID: Several times this week I've noticed no t on pickled yet 4-6 players on warped. Right now we have 3 on pickled and 5 on warped. I am formally petitioning the Developer Council (forget what it is called) if there is anything we can do about this problem? Zach From quozl at us.netrek.org Fri Jul 18 01:33:57 2008 From: quozl at us.netrek.org (James Cameron) Date: Fri, 18 Jul 2008 16:33:57 +1000 Subject: [netrek-dev] bronco t problem In-Reply-To: References: Message-ID: <20080718063357.GA19078@us.netrek.org> On Thu, Jul 17, 2008 at 05:34:25PM -0400, Zach Uram wrote: > Several times this week I've noticed no t on pickled yet 4-6 players > on warped. Right now we have 3 on pickled and 5 on warped. This has been happening for months, or even years. Why are you so concerned now? Bored? > I am formally petitioning the Developer Council (forget what it is > called) if there is anything we can do about this problem? There is a Netrek Infrastructure Team, consisting of Carlos Y. Villalpando, Dave Ahn, Karthik Arumugham, and James Cameron. If you have a matter relating to Netrek infrastructure which you would like addressed, please mail the team, at: carlos at jpl.nasa.gov,ahn at orion.netrek.org,karthik at karthik.com,quozl at us.netrek.org (That's according to the ServicesList page on the Netrek Development Wiki). Now, regarding your problem. It can be seen in another way. You find yourself unable to play on warped due to the feature mix, and you wish that everyone who does accept the feature mix on warped would not do so. The same could be said of the players there. They find themselves unable to play on picked due to the feature mix, and they wish that everyone who does accept that feature mix on pickled would not do so. It sounds very similar to arguments about other feature mixes. My opinion is that warped should be removed from metaservers and be blocked by client programs, because we have too few players to justify having more than one or two active servers splitting the available players. But this is not an autocracy with me at the head. Thank God. Others in the infrastructure team have views that conflict with mine, but that doesn't mean I can't continue to work with them. What we do agree on, we will do. So is there anything the infrastructure *can* do about the problem? Not really. We might try to block warped, but the blocks would be trivially circumvented. So is there anything the infrastructure team *will* do about the problem? Yes, we'll maintain the infrastructure as independently as possible, regardless of the feature mix of client or server that the player population demands. In this hope we will sustain an environment that will welcome Bronco players. p.s. I'm speaking for me, not the team. What can others do? - uninvolved developers, can provide independent builds of the most popular clients, independently of the primary developers, so that greater trust in the process can develop, so that single developers do not become unnecessarily powerful, - players, can stop bringing this issue up, but instead spend all their time on the server with the feature mix they prefer, and participate in development to ensure the clients have the features that bring in new players, - client developers, can add features that are actually needed to bring in new players, - server developers, need to add appropriate server side support for features that will bring in new players. Great, Zach, by raising it again, you help both sides of the debate. -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ From billbalcerski at gmail.com Mon Jul 21 19:09:27 2008 From: billbalcerski at gmail.com (Bill Balcerski) Date: Mon, 21 Jul 2008 20:09:27 -0400 Subject: [netrek-dev] Netrek XP 2009 v1.0 released Message-ID: <45ab86180807211709q25de6a92yad106b2325d5d661@mail.gmail.com> Greetings, I've released the latest version of the Windows client, which has been renamed to Netrek XP 2009. The client is available for download at http://www.netrek.org/files/NetrekXP_2009/netrekinstall2009v1.exe and the source code is available at http://netrek.cvs.sourceforge.net/netrek/client/netrekxp/ or at http://www.netrek.org/files/NetrekXP_2009/. Changes and fixes are as follows: Netrek XP 2009, Version 1.0: (Released July-2008) General bug fixes: 1) Fix to cloak bug where ships would briefly be seen to flash when entering tactical. 2) Various bug fixes for play on a paradise server. New features: 1) Addition of 3rd metaserver to the metaserver list. 2) Added support for new server feature packets (lame_refit, whydead_2, generic_32_b). 3) Added new timerType option for displaying useful game-related timers like surrender, sb reconstruct, INL, and t mode duration. 4) Added game paused message to local window (at TTS location) if server is paused, such as during an INL timeout. General changes: 1) Removed option for ship specific netrekrc file (rcfile-). Still can use ship specific keymaps and buttonmaps. Enjoy! Bill From quozl at us.netrek.org Tue Jul 22 05:51:51 2008 From: quozl at us.netrek.org (James Cameron) Date: Tue, 22 Jul 2008 20:51:51 +1000 Subject: [netrek-dev] netrek-client-cow-3.2.5 released Message-ID: <20080722105151.GA2835@us.netrek.org> netrek-client-cow 3.2.5 was released, containing extensive refinements to the metaserver window, improved handling of server disconnection, better integration with ICCM window managers, and a new window is opened for play when in metaserver mode. Also adds a mercenary mode, where hitting space or enter during team selection will join the least represented team, or a random team if no players are present on the server. The same key also returns to the game after death, using the current team and ship type. This is a backport of a Pygame client feature. http://quozl.linux.org.au/netrek/ 8b8accc0b318127a4c3e91b2c373efa9 netrek-client-cow-3.2.5.tar.gz Summary of changes: - default fullscreen to off, it was causing problems for those with incomplete resolution support on their systems, - team selection window, provide space bar or enter key to re-enter previous team with previous ship type, or join the second largest team, or join a random team if the server is empty, handle server disconnection gracefully without hanging or terminating, remove team selection options when a request is in progress, quit more quickly, - metaserver window, add a help window, default list size, - metaserver window, add arrow keys to select, space or enter to join, 'o' to observe, - fix to allow windows to be closed by user actions via window manager, without crashing the program, - allow metaserver window to resize when number of servers listed changes. - allow user to override login name using .xtrekrc. - keep metaserver window visible and use new window for each play session. Many compiler warnings were also reduced. -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20080722/f7591109/attachment.pgp From quozl at us.netrek.org Wed Jul 23 06:39:18 2008 From: quozl at us.netrek.org (James Cameron) Date: Wed, 23 Jul 2008 21:39:18 +1000 Subject: [netrek-dev] netrek-client-cow-3.2.5 released In-Reply-To: <20080722105151.GA2835@us.netrek.org> References: <20080722105151.GA2835@us.netrek.org> Message-ID: <20080723113918.GA9305@us.netrek.org> Debian packages for 3.2.5 have been carved. http://quozl.linux.org.au/netrek/ -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ From quozl at us.netrek.org Wed Jul 23 19:06:29 2008 From: quozl at us.netrek.org (James Cameron) Date: Thu, 24 Jul 2008 10:06:29 +1000 Subject: [netrek-dev] [PATCH] BRMH 2.5 segfault on pickled Message-ID: <20080724000629.GA10718@us.netrek.org> The following patch should prevent BRMH 2.5 beta from generating a segmentation fault on any server that has more features than the client list. --- brmh-dev-20071022.orig/feature.c 2007-10-09 02:32:24.000000000 +1000 +++ brmh-dev-20071022/feature.c 2008-07-24 10:04:24.000000000 +1000 @@ -140,8 +140,7 @@ if (features[i].name == 0) { fprintf(stderr, "Feature %s from server unknown to client!\n", packet->name); - } - if (!strcmp(features[i].name, "UPS")) + } else if (!strcmp(features[i].name, "UPS")) { cloak_phases = F_ups * 2 - 3; if (cloak_phases < 3) -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ From quozl at us.netrek.org Wed Jul 23 20:23:30 2008 From: quozl at us.netrek.org (James Cameron) Date: Thu, 24 Jul 2008 11:23:30 +1000 Subject: [netrek-dev] netrek-client-cow-3.2.5 released In-Reply-To: <20080723113918.GA9305@us.netrek.org> References: <20080722105151.GA2835@us.netrek.org> <20080723113918.GA9305@us.netrek.org> Message-ID: <20080724012330.GA10345@us.netrek.org> Debian packages for 3.2.5 have been carved again, using Etch as basis. http://quozl.linux.org.au/netrek/ -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ From joe at romulus.netrek.org Wed Jul 23 21:23:40 2008 From: joe at romulus.netrek.org (Joe Evango) Date: Wed, 23 Jul 2008 19:23:40 -0700 Subject: [netrek-dev] config utility update in xp 2009 Message-ID: <001b01c8ed34$49d22410$0201a8c0@joesmain> Config utility in XP 2009 had a bug that would cause the application to error out when saving a configuration. It has been fixed. If you find any newbies having issues with it please ask them to download the updated version of XP 2009 from netrek.org. Thank you, Joe From quozl at us.netrek.org Wed Jul 23 23:33:48 2008 From: quozl at us.netrek.org (James Cameron) Date: Thu, 24 Jul 2008 14:33:48 +1000 Subject: [netrek-dev] config utility update in xp 2009 In-Reply-To: <001b01c8ed34$49d22410$0201a8c0@joesmain> References: <001b01c8ed34$49d22410$0201a8c0@joesmain> Message-ID: <20080724043348.GB12398@us.netrek.org> On Wed, Jul 23, 2008 at 07:23:40PM -0700, Joe Evango wrote: > It has been fixed. If you find any newbies having issues with it > please ask them to download the updated version of XP 2009 from > netrek.org. http://netrek.org/files/NetrekXP_2009/ shows no change to file dates for the .exe ... is that right? -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ From billbalcerski at gmail.com Thu Jul 24 08:01:50 2008 From: billbalcerski at gmail.com (Bill Balcerski) Date: Thu, 24 Jul 2008 09:01:50 -0400 Subject: [netrek-dev] config utility update in xp 2009 In-Reply-To: <20080724043348.GB12398@us.netrek.org> References: <001b01c8ed34$49d22410$0201a8c0@joesmain> <20080724043348.GB12398@us.netrek.org> Message-ID: <45ab86180807240601v6b3e4ce3n7696349c1170140c@mail.gmail.com> On Thu, Jul 24, 2008 at 12:33 AM, James Cameron wrote: > http://netrek.org/files/NetrekXP_2009/ shows no change to file dates for > the .exe ... is that right? > [ ] netrekinstall2009v1.exe 23-Jul-2008 23:47 8.5M I've tested and confirmed the version on website has a working config utility. I uploaded it about an hour after Joe's email. Bill From joe at romulus.netrek.org Thu Jul 24 07:53:36 2008 From: joe at romulus.netrek.org (Joe Evango) Date: Thu, 24 Jul 2008 05:53:36 -0700 Subject: [netrek-dev] config utility update in xp 2009 References: <001b01c8ed34$49d22410$0201a8c0@joesmain> <20080724043348.GB12398@us.netrek.org> Message-ID: <000901c8ed8c$4a7c65d0$0201a8c0@joesmain> The netrekinstall2009v1.exe file has a modify date/time of 23-Jul-2008 23:47. This modify date/time is correct. -Joe ----- Original Message ----- From: "James Cameron" To: "Netrek Development Mailing List" Sent: Wednesday, July 23, 2008 9:33 PM Subject: Re: [netrek-dev] config utility update in xp 2009 > On Wed, Jul 23, 2008 at 07:23:40PM -0700, Joe Evango wrote: >> It has been fixed. If you find any newbies having issues with it >> please ask them to download the updated version of XP 2009 from >> netrek.org. > > http://netrek.org/files/NetrekXP_2009/ shows no change to file dates for > the .exe ... is that right? > > -- > James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ > > _______________________________________________ > netrek-dev mailing list > netrek-dev at us.netrek.org > http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > From quozl at us.netrek.org Tue Jul 29 07:08:02 2008 From: quozl at us.netrek.org (James Cameron) Date: Tue, 29 Jul 2008 22:08:02 +1000 Subject: [netrek-dev] netrek-client-cow-3.2.6 released Message-ID: <20080729120802.GA32236@us.netrek.org> netrek-client-cow 3.2.6 was released, adding visible tractors for other ships when supplied by server, improving observer view, adding a fast guest login feature on the metaserver list (one click to play), reworking login to avoid display hangs when a server or link is slow, and handling disconnection during play more gracefully. http://quozl.linux.org.au/netrek/ bce924f63bb81de064461b30899b95cd netrek-client-cow-3.2.6.tar.gz Summary of changes: - add visible tractors for all ships, using the SHOW_ALL_TRACTORS feature set, - remove the observer ghost ship, shield ring, and ship number, draw the observed player as if it is the player, - metaserver window, remove all display delays, add a fast guest login feature using middle mouse button, add a cyclic refresh at 30 second interval, show result of playing on a server (e.g. pass through any connection failure, banned, or other problems so that they appear on the list), - login window, provide full screen refresh, don't hang when waiting for the server to respond, use colours to highlight, - team selection window, realignment of auto quit button, explain that the message of the day is from the server, explain the enter key joins a default team, realignment of message of the day, - disconnection during play, continue to show tactical and galactic state, advise user through a warning message, allow user controlled exit, show the result on the metaserver list, - add a newbie message window hint, backported from Netrek XP 2009, - fix unknown feature warnings on pickled, - provide slot change support, potential future feature, no server expected to use it yet, - add pointer to maintainer, build for Debian Etch, point to autogen in documentation. -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20080729/cab8362e/attachment.pgp From jka at inthewings.net Tue Jul 29 11:05:59 2008 From: jka at inthewings.net (Jon Akers) Date: Tue, 29 Jul 2008 12:05:59 -0400 Subject: [netrek-dev] netrek-client-cow-3.2.6 released In-Reply-To: <20080729120802.GA32236@us.netrek.org> References: <20080729120802.GA32236@us.netrek.org> Message-ID: <488F3FE7.5030503@inthewings.net> Looks like there is at least one problem with this new release in sensors.c: socket.c:2268: warning: array subscript has type 'char' socket.c: In function 'handlePStatus': socket.c:2297: warning: array subscript has type 'char' socket.c:2325: warning: array subscript has type 'char' socket.c:2330: warning: array subscript has type 'char' socket.c: In function 'handleBadVersion': socket.c:2430: error: 'MAXBADVERSION' undeclared (first use in this function) socket.c:2430: error: (Each undeclared identifier is reported only once socket.c:2430: error: for each function it appears in.) socket.c:2431: error: 'badversion_long_strings' undeclared (first use in this fu nction) socket.c: In function 'handleReserved': socket.c:2727: warning: implicit declaration of function 'encryptReservedPacket' socket.c: In function 'recvUdpConn': socket.c:3278: warning: implicit declaration of function 'ns_init' make[1]: *** [socket.o] Error 1 make[1]: Leaving directory `/tmp/portage/games-simulation/netrek-client-cow-3.2. 6/work/netrek-client-cow-3.2.6' make: *** [netrekI] Error 2 Checking against 3.2.5, the MAXBADVERSION variable does not exist. I am building this on a mips box that I have, which is probably why I also get a ton of warnings as well. James Cameron wrote: > netrek-client-cow 3.2.6 was released, adding visible tractors for other > ships when supplied by server, improving observer view, adding a fast > guest login feature on the metaserver list (one click to play), > reworking login to avoid display hangs when a server or link is slow, > and handling disconnection during play more gracefully. > > http://quozl.linux.org.au/netrek/ > bce924f63bb81de064461b30899b95cd netrek-client-cow-3.2.6.tar.gz > > Summary of changes: > > - add visible tractors for all ships, using the SHOW_ALL_TRACTORS > feature set, > > - remove the observer ghost ship, shield ring, and ship number, > draw the observed player as if it is the player, > > - metaserver window, remove all display delays, add a fast guest > login feature using middle mouse button, add a cyclic refresh at > 30 second interval, show result of playing on a server (e.g. pass > through any connection failure, banned, or other problems so that > they appear on the list), > > - login window, provide full screen refresh, don't hang when > waiting for the server to respond, use colours to highlight, > > - team selection window, realignment of auto quit button, explain > that the message of the day is from the server, explain the enter > key joins a default team, realignment of message of the day, > > - disconnection during play, continue to show tactical and > galactic state, advise user through a warning message, allow user > controlled exit, show the result on the metaserver list, > > - add a newbie message window hint, backported from Netrek XP 2009, > > - fix unknown feature warnings on pickled, > > - provide slot change support, potential future feature, no server > expected to use it yet, > > - add pointer to maintainer, build for Debian Etch, point to > autogen in documentation. > > > ------------------------------------------------------------------------ > > _______________________________________________ > netrek-dev mailing list > netrek-dev at us.netrek.org > http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > From quozl at us.netrek.org Tue Jul 29 18:06:05 2008 From: quozl at us.netrek.org (James Cameron) Date: Wed, 30 Jul 2008 09:06:05 +1000 Subject: [netrek-dev] netrek-client-cow-3.2.6 released In-Reply-To: <488F3FE7.5030503@inthewings.net> References: <20080729120802.GA32236@us.netrek.org> <488F3FE7.5030503@inthewings.net> Message-ID: <20080729230605.GB5615@us.netrek.org> On Tue, Jul 29, 2008 at 12:05:59PM -0400, Jon Akers wrote: > Looks like there is at least one problem with this new release in sensors.c: socket.c, yes. badversion.h was missed out of manifest and therefore wasn't in the make dist .tar.gz ... fixed in darcs. > Checking against 3.2.5, the MAXBADVERSION variable does not exist. Yes, badversion.h is new. > I am building this on a mips box that I have, which is probably why I > also get a ton of warnings as well. No, I get those warnings too, we recently enabled -Wall and have been reducing the warnings since. We're down to about half or a third of what they were before -Wall was turned on. -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ From quozl at us.netrek.org Tue Jul 29 21:03:14 2008 From: quozl at us.netrek.org (James Cameron) Date: Wed, 30 Jul 2008 12:03:14 +1000 Subject: [netrek-dev] netrek-client-cow-3.2.6 released In-Reply-To: <20080729120802.GA32236@us.netrek.org> References: <20080729120802.GA32236@us.netrek.org> Message-ID: <20080730020314.GA27629@us.netrek.org> Debian GNU/Linux Etch build complete. Choices: 1. if you have an i386, and have http://quozl.linux.org.au/netrek in your sources list, aptitude update && aptitude install netrek-client-cow 2. if you have an i386 system, grab the .deb and install, wget http://netrek.org/files/COW/netrek-client-cow_3.2.6-0_i386.deb dpkg --install netrek-client-cow_3.2.6-0_i386.deb 3. if you have another architecture, add http://quozl.linux.org.au/netrek to your deb-src list, then apt-get update apt-get source --compile netrek-client-cow If you're on Ubuntu, let me know how it goes. Anyone got an x86_64 host willing to do builds? -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ From msucka0xff at programmer.net Wed Jul 30 11:09:09 2008 From: msucka0xff at programmer.net (. .) Date: Wed, 30 Jul 2008 08:09:09 -0800 Subject: [netrek-dev] netrek-client-cow-3.2.6 released Message-ID: <20080730160911.698281158CC@ws1-7.us4.outblaze.com> bd at dice:~/netrek/netrek-client-cow$ uname -a Linux dice 2.6.22-14-generic #1 SMP Tue Feb 12 02:46:46 UTC 2008 x86_64 GNU/Linux bd at dice:~/netrek/netrek-client-cow$ date Wed Jul 30 09:00:33 PDT 2008 bd at dice:~/netrek$ darcs get http://james.tooraweenah.com/darcs/netrek-client-cow/ Copying patch 253 of 253... done! Applying patch 253 of 253... done. Finished getting. bd at dice:~/netrek/netrek-client-cow$ source ./autogen.sh The program 'aclocal' can be found in the following packages: * automake * automake1.4 * automake1.7 * automake1.9 * automake1.8 Try: sudo apt-get install bash: aclocal: command not found The program 'libtoolize' is currently not installed. You can install it by typing: sudo apt-get install libtool bash: libtoolize: command not found The program 'autoconf' can be found in the following packages: * autoconf * autoconf2.13 Try: sudo apt-get install bash: autoconf: command not found autogen.sh completed ok bd at dice:~/netrek/netrek-client-cow$ sudo apt-get install automake bd at dice:~/netrek/netrek-client-cow$ sudo apt-get install libtool bd at dice:~/netrek/netrek-client-cow$ ./configure checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking target system type... x86_64-unknown-linux-gnu checking your key... checking release type... unstable checking for a BSD-compatible install... /usr/bin/install -c checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking how to run the C preprocessor... gcc -E checking whether ln -s works... yes checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for AIX... no checking for inline... inline checking if fd_set requires sys/select.h... no checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for unistd.h... (cached) yes checking for memory.h... (cached) yes checking math.h usability... yes checking math.h presence... yes checking for math.h... yes checking for stdlib.h... (cached) yes checking sys/timeb.h usability... yes checking sys/timeb.h presence... yes checking for sys/timeb.h... yes checking sys/ptyio.h usability... no checking sys/ptyio.h presence... no checking for sys/ptyio.h... no checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking ctype.h usability... yes checking ctype.h presence... yes checking for ctype.h... yes checking machine/endian.h usability... no checking machine/endian.h presence... no checking for machine/endian.h... no checking sys/resource.h usability... yes checking sys/resource.h presence... yes checking for sys/resource.h... yes checking sys/wait.h usability... yes checking sys/wait.h presence... yes checking for sys/wait.h... yes checking netinet/in.h usability... yes checking netinet/in.h presence... yes checking for netinet/in.h... yes checking netinet/tcp.h usability... yes checking netinet/tcp.h presence... yes checking for netinet/tcp.h... yes checking sys/filio.h usability... no checking sys/filio.h presence... no checking for sys/filio.h... no checking for wait3 that fills in rusage... yes checking for pid_t... yes checking for uid_t in sys/types.h... yes checking for size_t... yes checking vfork.h usability... no checking vfork.h presence... no checking for vfork.h... no checking for fork... yes checking for vfork... yes checking for working fork... yes checking for working vfork... (cached) yes checking whether struct tm is in sys/time.h or time.h... time.h checking for itimer in time.h... no checking for long... yes checking size of long... 8 checking for u_int in sys/types.h... yes checking for PATH_MAX in limits.h... yes checking for strcmpi... no checking for strncmpi... no checking for X... no checking for main in -lgdi32... no checking for main in -lXpm... no checking X11/xpm.h usability... no checking X11/xpm.h presence... no checking for X11/xpm.h... no checking for mp.h... yes checking for gmp.h... no checking for main in -lmp... no Warning mp or gmp library not found, turning RSA off. RSA utilities for COW build found. checking for main in -lXbsd... no checking for main in -lsocket... no checking for main in -linet... no checking for main in -lnsl... no checking for main in -lseq... no checking for main in -lsun... no checking return type of signal handlers... void checking for sys/wait.h that is POSIX.1 compatible... (cached) yes checking for restartable system calls... no checking for signals style... SYSV_or_POSIX checking for sigset... no checking for usleep... no checking for random... no checking for setstate... no checking for strftime... no checking for ftime... no checking for main in -lm... no checking for nint... no checking for usleep... (cached) no checking for setstate... (cached) no checking for strdup... no checking for rint... no ./configure: line 8044: syntax error near unexpected token `1.2.4,' ./configure: line 8044: `AM_PATH_SDL(1.2.4, cat >>confdefs.h <<\_ACEOF' bd at dice:~/netrek/netrek-client-cow$ sudo apt-get install libsdl-mixer1.2 libsdl-mixer1.2-dev bd at dice:~/netrek/netrek-client-cow$ tail -n 15 configure.in AC_PROG_LIBTOOL(/usr/bin/libtool) AM_PATH_SDL(1.2.4, AC_DEFINE(HAVE_SDL),[]) AM_CONDITIONAL(HAVE_SDL, [test x"$no_sdl" != x"yes"]) if test x$no_sdl != xyes; then have_SDLmixer=no AC_CHECK_LIB(SDL_mixer, Mix_OpenAudio, [have_SDLmixer=yes SDL_MIXER_LIBS="-lSDL_mixer"]) if test x$have_SDLmixer != xyes; then AC_MSG_ERROR([*** Can't find the SDL_mixer library Try: http://www.libsdl.org/projects/SDL_mixer/]) AC_SUBST(SDL_MIXER_LIBS) fi fi AC_OUTPUT(system.mk key.mk) bd at dice:~/netrek/netrek-client-cow$ ./configure checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking target system type... x86_64-unknown-linux-gnu checking your key... checking release type... unstable checking for a BSD-compatible install... /usr/bin/install -c checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking how to run the C preprocessor... gcc -E checking whether ln -s works... yes checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for AIX... no checking for inline... inline checking if fd_set requires sys/select.h... no checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for unistd.h... (cached) yes checking for memory.h... (cached) yes checking math.h usability... yes checking math.h presence... yes checking for math.h... yes checking for stdlib.h... (cached) yes checking sys/timeb.h usability... yes checking sys/timeb.h presence... yes checking for sys/timeb.h... yes checking sys/ptyio.h usability... no checking sys/ptyio.h presence... no checking for sys/ptyio.h... no checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking ctype.h usability... yes checking ctype.h presence... yes checking for ctype.h... yes checking machine/endian.h usability... no checking machine/endian.h presence... no checking for machine/endian.h... no checking sys/resource.h usability... yes checking sys/resource.h presence... yes checking for sys/resource.h... yes checking sys/wait.h usability... yes checking sys/wait.h presence... yes checking for sys/wait.h... yes checking netinet/in.h usability... yes checking netinet/in.h presence... yes checking for netinet/in.h... yes checking netinet/tcp.h usability... yes checking netinet/tcp.h presence... yes checking for netinet/tcp.h... yes checking sys/filio.h usability... no checking sys/filio.h presence... no checking for sys/filio.h... no checking for wait3 that fills in rusage... yes checking for pid_t... yes checking for uid_t in sys/types.h... yes checking for size_t... yes checking vfork.h usability... no checking vfork.h presence... no checking for vfork.h... no checking for fork... yes checking for vfork... yes checking for working fork... yes checking for working vfork... (cached) yes checking whether struct tm is in sys/time.h or time.h... time.h checking for itimer in time.h... no checking for long... yes checking size of long... 8 checking for u_int in sys/types.h... yes checking for PATH_MAX in limits.h... yes checking for strcmpi... no checking for strncmpi... no checking for X... libraries , headers checking for main in -lgdi32... no checking for X11 header files Warning: couldn't find any X11 include files. checking for X11 library archive checking for main in -lX11... yes checking for main in -lXpm... no checking X11/xpm.h usability... no checking X11/xpm.h presence... no checking for X11/xpm.h... no checking for mp.h... yes checking for gmp.h... no checking for main in -lmp... no Warning mp or gmp library not found, turning RSA off. RSA utilities for COW build found. checking for main in -lXbsd... no checking for main in -lsocket... no checking for main in -linet... no checking for main in -lnsl... yes checking for main in -lseq... no checking for main in -lsun... no checking return type of signal handlers... void checking for sys/wait.h that is POSIX.1 compatible... (cached) yes checking for restartable system calls... yes checking for signals style... BSD checking for usleep... yes checking for random... yes checking for setstate... yes checking for strftime... yes checking for ftime... yes checking for main in -lm... yes checking for nint... no checking for usleep... (cached) yes checking for setstate... (cached) yes checking for strdup... yes checking for rint... yes checking for a sed that does not truncate output... /bin/sed checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking how to recognize dependent libraries... pass_all checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... no checking for xlf... no checking for f77... no checking for frt... no checking for pgf77... no checking for cf77... no checking for fort77... no checking for fl32... no checking for af77... no checking for xlf90... no checking for f90... no checking for pgf90... no checking for pghpf... no checking for epcf90... no checking for gfortran... no checking for g95... no checking for xlf95... no checking for f95... no checking for fort... no checking for ifort... no checking for ifc... no checking for efc... no checking for pgf95... no checking for lf95... no checking for ftn... no checking whether we are using the GNU Fortran 77 compiler... no checking whether accepts -g... no checking the maximum length of command line arguments... 98304 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc static flag -static works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld -m elf_x86_64 checking if the linker (/usr/bin/ld -m elf_x86_64) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ static flag -static works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate appending configuration tag "F77" to libtool checking for sdl-config... /usr/bin/sdl-config checking for SDL - version >= 1.2.4... yes checking for Mix_OpenAudio in -lSDL_mixer... yes configure: creating ./config.status config.status: creating system.mk config.status: creating key.mk config.status: creating config.h bd at dice:~/netrek/netrek-client-cow$ make make -f system.mk KEYDEF=sample_key.def netrek make[1]: Entering directory `/home/bd/netrek/netrek-client-cow' gcc -g -Wall -c -o check.o check.c gcc -g -Wall -c -o colors.o colors.c gcc -g -Wall -c -o data.o data.c gcc -g -Wall -c -o death.o death.c gcc -g -Wall -c -o defaults.o defaults.c defaults.c:105: warning: return type defaults to ?int? defaults.c: In function ?initDefaults?: defaults.c:134: warning: implicit declaration of function ?getshipdefaults? defaults.c:140: warning: ?return? with no value, in function returning non-void defaults.c:136: warning: suggest explicit braces to avoid ambiguous ?else? defaults.c:144: warning: ?return? with no value, in function returning non-void defaults.c:414: warning: implicit declaration of function ?malloc? defaults.c:414: warning: incompatible implicit declaration of built-in function ?malloc? defaults.c:108: warning: unused variable ?home? defaults.c: At top level: defaults.c:449: warning: return type defaults to ?int? defaults.c:480: warning: return type defaults to ?int? defaults.c:513: warning: return type defaults to ?int? defaults.c:532: warning: return type defaults to ?int? defaults.c: In function ?intDefault?: defaults.c:538: warning: implicit declaration of function ?atoi? defaults.c: At top level: defaults.c:571: warning: return type defaults to ?int? defaults.c: In function ?resetdefaults?: defaults.c:783: warning: implicit declaration of function ?litedefaults? defaults.c:805: warning: suggest parentheses around assignment used as truth value defaults.c:812: warning: suggest parentheses around assignment used as truth value defaults.c:819: warning: suggest parentheses around assignment used as truth value defaults.c:826: warning: suggest parentheses around assignment used as truth value defaults.c:575: warning: unused variable ?tmp_int? defaults.c:832: warning: control reaches end of non-void function defaults.c: At top level: defaults.c:835: warning: return type defaults to ?int? defaults.c: In function ?shipchange?: defaults.c:837: warning: ?return? with no value, in function returning non-void defaults.c:845: warning: implicit declaration of function ?initkeymap? defaults.c: At top level: defaults.c:84: warning: ?prob_desc? defined but not used defaults.c:86: warning: ?prob_severity? defined but not used gcc -g -Wall -c -o dmessage.o dmessage.c dmessage.c:31: warning: return type defaults to ?int? dmessage.c: In function ?dmessage?: dmessage.c:50: warning: passing argument 1 of ?time? from incompatible pointer type dmessage.c:51: warning: passing argument 1 of ?localtime? from incompatible pointer type dmessage.c:72: warning: implicit declaration of function ?HandleGenDistr? dmessage.c:73: warning: implicit declaration of function ?makedistress? dmessage.c:77: warning: implicit declaration of function ?rcdlite? dmessage.c:81: warning: ?return? with no value, in function returning non-void dmessage.c:104: warning: implicit declaration of function ?instr? dmessage.c:113: warning: implicit declaration of function ?CheckFeatures? dmessage.c:114: warning: ?return? with no value, in function returning non-void dmessage.c:123: warning: implicit declaration of function ?pmessage? dmessage.c:132: warning: ?return? with no value, in function returning non-void dmessage.c:171: warning: ?return? with no value, in function returning non-void dmessage.c:187: warning: ?return? with no value, in function returning non-void dmessage.c:37: warning: unused variable ?buf? dmessage.c: At top level: dmessage.c:261: warning: return type defaults to ?int? dmessage.c:275: warning: return type defaults to ?int? dmessage.c: In function ?nothing?: dmessage.c:276: warning: unused variable ?foo? dmessage.c:280: warning: control reaches end of non-void function dmessage.c: At top level: dmessage.c:283: warning: return type defaults to ?int? dmessage.c: In function ?CheckFeatures?: dmessage.c:288: warning: ?return? with no value, in function returning non-void dmessage.c: At top level: dmessage.c:369: warning: return type defaults to ?int? dmessage.c: In function ?sendVersion?: dmessage.c:379: warning: control reaches end of non-void function gcc -g -Wall -c -o enter.o enter.c gcc -g -Wall -c -o findslot.o findslot.c gcc -g -Wall -c -o getname.o getname.c gcc -g -Wall -c -o getship.o getship.c gcc -g -Wall -c -o helpwin.o helpwin.c gcc -g -Wall -c -o inform.o inform.c gcc -g -Wall -c -o interface.o interface.c interface.c:34: warning: return type defaults to ?int? interface.c: In function ?set_speed?: interface.c:35: warning: implicit declaration of function ?sendShortPacket? interface.c:36: warning: control reaches end of non-void function interface.c: At top level: interface.c:39: warning: return type defaults to ?int? interface.c: In function ?set_course?: interface.c:41: warning: control reaches end of non-void function interface.c: At top level: interface.c:44: warning: return type defaults to ?int? interface.c: In function ?shield_up?: interface.c:49: warning: control reaches end of non-void function interface.c: At top level: interface.c:52: warning: return type defaults to ?int? interface.c: In function ?shield_down?: interface.c:57: warning: control reaches end of non-void function interface.c: At top level: interface.c:60: warning: return type defaults to ?int? interface.c: In function ?shield_tog?: interface.c:69: warning: control reaches end of non-void function interface.c: At top level: interface.c:72: warning: return type defaults to ?int? interface.c: In function ?bomb_planet?: interface.c:77: warning: control reaches end of non-void function interface.c: At top level: interface.c:80: warning: return type defaults to ?int? interface.c: In function ?beam_up?: interface.c:85: warning: control reaches end of non-void function interface.c: At top level: interface.c:88: warning: return type defaults to ?int? interface.c: In function ?beam_down?: interface.c:93: warning: control reaches end of non-void function interface.c: At top level: interface.c:96: warning: return type defaults to ?int? interface.c: In function ?repair?: interface.c:101: warning: control reaches end of non-void function interface.c: At top level: interface.c:104: warning: return type defaults to ?int? interface.c: In function ?repair_off?: interface.c:109: warning: control reaches end of non-void function interface.c: At top level: interface.c:112: warning: return type defaults to ?int? interface.c: In function ?repeat_message?: interface.c:115: warning: control reaches end of non-void function interface.c: At top level: interface.c:118: warning: return type defaults to ?int? interface.c: In function ?cloak?: interface.c:127: warning: control reaches end of non-void function interface.c: At top level: interface.c:130: warning: return type defaults to ?int? interface.c: In function ?cloak_on?: interface.c:135: warning: control reaches end of non-void function interface.c: At top level: interface.c:138: warning: return type defaults to ?int? interface.c: In function ?cloak_off?: interface.c:143: warning: control reaches end of non-void function interface.c: At top level: interface.c:187: warning: return type defaults to ?int? interface.c: In function ?run_clock?: interface.c:194: warning: ?return? with no value, in function returning non-void gcc -g -Wall -c -o newwin.o newwin.c newwin.c: In function ?handleMessageWindowButton?: newwin.c:109: warning: implicit declaration of function ?pastebuffer? newwin.c:113: warning: implicit declaration of function ?Key109? newwin.c: In function ?newwin?: newwin.c:146: warning: implicit declaration of function ?booleanDefault? newwin.c:255: warning: implicit declaration of function ?lMeterWidth? newwin.c:255: warning: implicit declaration of function ?lMeterHeight? newwin.c:259: warning: implicit declaration of function ?pStatsWidth? newwin.c:259: warning: implicit declaration of function ?pStatsHeight? newwin.c:358: warning: implicit declaration of function ?getResources? newwin.c:359: warning: implicit declaration of function ?savebitmaps? newwin.c: In function ?mapAll?: newwin.c:381: warning: implicit declaration of function ?checkMapped? newwin.c:396: warning: implicit declaration of function ?nswindow? newwin.c:406: warning: implicit declaration of function ?checkMappedPref? newwin.c: At top level: newwin.c:421: warning: return type defaults to ?int? newwin.c: In function ?savebitmaps?: newwin.c:714: warning: control reaches end of non-void function newwin.c: In function ?entrywindow?: newwin.c:850: warning: implicit declaration of function ?run_clock? newwin.c:851: warning: implicit declaration of function ?updatedeath? newwin.c:858: warning: implicit declaration of function ?intDefault? newwin.c:876: warning: implicit declaration of function ?isServerDead? newwin.c:877: warning: implicit declaration of function ?sendTeamReq? newwin.c:886: warning: implicit declaration of function ?warning? newwin.c:917: warning: implicit declaration of function ?readFromServer? newwin.c:949: warning: implicit declaration of function ?map? newwin.c:956: warning: implicit declaration of function ?showTimeLeft? newwin.c:969: warning: implicit declaration of function ?redrawTeam? newwin.c:1049: warning: implicit declaration of function ?sendShortPacket? newwin.c:1122: warning: implicit declaration of function ?redrawQuit? newwin.c: At top level: newwin.c:1179: warning: return type defaults to ?int? newwin.c: In function ?showMotd?: newwin.c:1232: warning: implicit declaration of function ?query_cowid? newwin.c:1232: warning: cast to pointer from integer of different size newwin.c:1310: warning: implicit declaration of function ?showValues? newwin.c: At top level: newwin.c:1315: warning: return type defaults to ?int? newwin.c: In function ?showValues?: newwin.c:1323: warning: ?return? with no value, in function returning non-void newwin.c: In function ?newMotdLine?: newwin.c:1366: warning: implicit declaration of function ?ClearMotd? newwin.c: At top level: newwin.c:1378: warning: return type defaults to ?int? newwin.c: In function ?ClearMotd?: newwin.c:1394: warning: control reaches end of non-void function newwin.c: At top level: newwin.c:1398: warning: return type defaults to ?int? newwin.c: In function ?getResources?: newwin.c:1399: warning: implicit declaration of function ?getColorDefs? newwin.c:1400: warning: implicit declaration of function ?getTiles? newwin.c:1401: warning: control reaches end of non-void function newwin.c: At top level: newwin.c:1404: warning: return type defaults to ?int? newwin.c: In function ?getTiles?: newwin.c:1406: warning: control reaches end of non-void function newwin.c: At top level: newwin.c:1409: warning: return type defaults to ?int? newwin.c: In function ?redrawTeam?: newwin.c:1417: warning: ?return? with no value, in function returning non-void newwin.c: At top level: newwin.c:1429: warning: return type defaults to ?int? newwin.c: In function ?redrawQuit?: newwin.c:1433: warning: control reaches end of non-void function newwin.c: At top level: newwin.c:1449: warning: return type defaults to ?int? newwin.c: In function ?showTimeLeft?: newwin.c:1470: warning: format ?%d? expects type ?int?, but argument 3 has type ?time_t? newwin.c:1479: warning: control reaches end of non-void function newwin.c: At top level: oldbitmaps.h:477: warning: ?cross_bits? defined but not used oldbitmaps.h:484: warning: ?crossmask_bits? defined but not used newwin.c:95: warning: ?teamRequest? declared ?static? but never defined newwin.c:1157: warning: ?deadTeam? defined but not used gcc -g -Wall -c -o option.o option.c option.c: In function ?optionaction?: option.c:782: warning: implicit declaration of function ?udpwindow? option.c:784: warning: implicit declaration of function ?redrawPStats? option.c:786: warning: implicit declaration of function ?nswindow? option.c:788: warning: implicit declaration of function ?spwindow? option.c:792: warning: implicit declaration of function ?showdef? option.c:802: warning: implicit declaration of function ?showdocs? option.c:805: warning: implicit declaration of function ?showxtrekrc? option.c: In function ?optiondone?: option.c:860: warning: implicit declaration of function ?sendUpdatePacket? option.c:863: warning: implicit declaration of function ?sendOptionsPacket? gcc -g -Wall -c -o planetlist.o planetlist.c gcc -g -Wall -c -o macrowin.o macrowin.c macrowin.c: In function ?filldist?: macrowin.c:96: warning: embedded ?\0? in format macrowin.c:98: warning: embedded ?\0? in format macrowin.c: In function ?fillmacro?: macrowin.c:131: warning: embedded ?\0? in format macrowin.c:137: warning: embedded ?\0? in format macrowin.c:155: warning: embedded ?\0? in format macrowin.c:157: warning: embedded ?\0? in format macrowin.c: In function ?switchmacros?: macrowin.c:231: warning: implicit declaration of function ?abs? macrowin.c:240: warning: implicit declaration of function ?W_ResizeTextWindow? macrowin.c: At top level: macrowin.c:249: warning: return type defaults to ?int? macrowin.c: In function ?showMacroWin?: macrowin.c:276: warning: control reaches end of non-void function gcc -g -Wall -c -o map.o map.c gcc -g -Wall -c -o playerlist.o playerlist.c gcc -g -Wall -c -o ranklist.o ranklist.c gcc -g -Wall -c -o reserved.o reserved.c reserved.c:36: warning: return type defaults to ?int? reserved.c: In function ?makeReservedPacket?: reserved.c:41: warning: implicit declaration of function ?random? reserved.c:44: warning: control reaches end of non-void function reserved.c: At top level: reserved.c:69: warning: return type defaults to ?int? reserved.c: In function ?encryptReservedPacket?: reserved.c:72: warning: unused variable ?address? reserved.c:71: warning: unused variable ?hp? reserved.c:123: warning: control reaches end of non-void function gcc -g -Wall -c -o sintab.o sintab.c gcc -g -Wall -c -o smessage.o smessage.c smessage.c: In function ?smessage?: smessage.c:132: warning: suggest parentheses around assignment used as truth value smessage.c:133: warning: cast from pointer to integer of different size smessage.c:146: warning: implicit declaration of function ?message_off? smessage.c:223: warning: implicit declaration of function ?pmessage? smessage.c:262: warning: implicit declaration of function ?warning? smessage.c: At top level: smessage.c:328: warning: return type defaults to ?int? smessage.c: In function ?pmessage?: smessage.c:341: warning: implicit declaration of function ?sendTools? smessage.c:359: warning: implicit declaration of function ?dmessage? smessage.c:362: warning: control reaches end of non-void function smessage.c: At top level: smessage.c:498: warning: return type defaults to ?int? smessage.c: In function ?message_on?: smessage.c:508: warning: control reaches end of non-void function smessage.c: At top level: smessage.c:511: warning: return type defaults to ?int? smessage.c: In function ?message_off?: smessage.c:515: warning: control reaches end of non-void function smessage.c: At top level: smessage.c:519: warning: return type defaults to ?int? smessage.c: In function ?message_hold?: smessage.c:525: warning: control reaches end of non-void function smessage.c: At top level: smessage.c:632: warning: return type defaults to ?int? smessage.c: In function ?pnbtmacro?: smessage.c:654: warning: control reaches end of non-void function gcc -g -Wall -c -o socket.o socket.c socket.c: In function ?connectToServer?: socket.c:786: warning: format ?%lx? expects type ?long unsigned int?, but argument 3 has type ?int? socket.c: At top level: socket.c:931: warning: return type defaults to ?int? socket.c:968: warning: return type defaults to ?int? socket.c: In function ?readFromServer?: socket.c:991: warning: implicit declaration of function ?dotimers? socket.c:1007: warning: implicit declaration of function ?warning? socket.c:982: warning: label ?tryagain? defined but not used socket.c: At top level: socket.c:1046: warning: return type defaults to ?int? socket.c: In function ?dotimers?: socket.c:1072: warning: control reaches end of non-void function socket.c: In function ?getvpsize?: socket.c:1111: warning: array subscript has type ?char? socket.c:1114: warning: array subscript has type ?char? socket.c: In function ?doRead?: socket.c:1174: warning: implicit declaration of function ?ns_record_update? socket.c:1239: warning: array subscript has type ?char? socket.c:1254: warning: array subscript has type ?char? socket.c:1313: warning: array subscript has type ?char? socket.c:1322: warning: implicit declaration of function ?ckRecordPacket? socket.c:1344: warning: array subscript has type ?char? socket.c:1279: warning: label ?tryagain1? defined but not used socket.c: In function ?handleSelf?: socket.c:1563: warning: array subscript has type ?char? socket.c: In function ?handlePlayer?: socket.c:1643: warning: array subscript has type ?char? socket.c:1677: warning: array subscript has type ?char? socket.c: At top level: socket.c:1717: warning: return type defaults to ?int? socket.c: In function ?sendShortPacket?: socket.c:1782: warning: control reaches end of non-void function socket.c: In function ?sendServerPacket?: socket.c:1791: warning: array subscript has type ?char? socket.c:1796: warning: array subscript has type ?char? socket.c:1819: warning: implicit declaration of function ?gwrite? socket.c: In function ?handlePlanet?: socket.c:1907: warning: array subscript has type ?char? socket.c: In function ?handlePhaser?: socket.c:1972: warning: array subscript has type ?char? socket.c: At top level: socket.c:2089: warning: return type defaults to ?int? socket.c: In function ?sendTractorReq?: socket.c:2101: warning: control reaches end of non-void function socket.c: At top level: socket.c:2104: warning: return type defaults to ?int? socket.c: In function ?sendRepressReq?: socket.c:2116: warning: control reaches end of non-void function socket.c: At top level: socket.c:2119: warning: return type defaults to ?int? socket.c: In function ?sendDetMineReq?: socket.c:2125: warning: control reaches end of non-void function socket.c: In function ?handleFlags?: socket.c:2214: warning: array subscript has type ?char? socket.c:2224: warning: array subscript has type ?char? socket.c:2227: warning: array subscript has type ?char? socket.c:2234: warning: array subscript has type ?char? socket.c:2239: warning: array subscript has type ?char? socket.c:2243: warning: array subscript has type ?char? socket.c:2247: warning: array subscript has type ?char? socket.c: In function ?handleKills?: socket.c:2261: warning: array subscript has type ?char? socket.c:2263: warning: array subscript has type ?char? socket.c:2265: warning: array subscript has type ?char? socket.c:2268: warning: array subscript has type ?char? socket.c: In function ?handlePStatus?: socket.c:2297: warning: array subscript has type ?char? socket.c:2325: warning: array subscript has type ?char? socket.c:2330: warning: array subscript has type ?char? socket.c: At top level: socket.c:2652: error: conflicting types for ?sendUpdatePacket? socket.h:52: error: previous declaration of ?sendUpdatePacket? was here socket.c: In function ?handleReserved?: socket.c:2727: warning: implicit declaration of function ?encryptReservedPacket? socket.c: In function ?openUdpConn?: socket.c:3228: warning: format ?%lx? expects type ?long unsigned int?, but argument 2 has type ?int? socket.c: In function ?connUdpConn?: socket.c:3242: warning: format ?%lx? expects type ?long unsigned int?, but argument 2 has type ?int? socket.c: In function ?recvUdpConn?: socket.c:3278: warning: implicit declaration of function ?ns_init? socket.c:3314: warning: format ?%lx? expects type ?long unsigned int?, but argument 3 has type ?int? socket.c: In function ?handleSequence?: socket.c:3439: warning: format ?%ld? expects type ?long int?, but argument 2 has type ?int? socket.c:3439: warning: format ?%ld? expects type ?long int?, but argument 3 has type ?int? socket.c:3454: warning: format ?%ld? expects type ?long int?, but argument 2 has type ?int? socket.c:3458: warning: format ?%ld? expects type ?long int?, but argument 2 has type ?int? socket.c:3458: warning: format ?%ld? expects type ?long int?, but argument 3 has type ?int? make[1]: *** [socket.o] Error 1 make[1]: Leaving directory `/home/bd/netrek/netrek-client-cow' make: *** [netrekI] Error 2 bd at dice:~/netrek/netrek-client-cow$ ----- Original Message ----- From: "James Cameron" To: netrek-dev at lists.netrek.org Subject: Re: [netrek-dev] netrek-client-cow-3.2.6 released Date: Wed, 30 Jul 2008 12:03:14 +1000 Debian GNU/Linux Etch build complete. Choices: 1. if you have an i386, and have http://quozl.linux.org.au/netrek in your sources list, aptitude update && aptitude install netrek-client-cow 2. if you have an i386 system, grab the .deb and install, wget http://netrek.org/files/COW/netrek-client-cow_3.2.6-0_i386.deb dpkg --install netrek-client-cow_3.2.6-0_i386.deb 3. if you have another architecture, add http://quozl.linux.org.au/netrek to your deb-src list, then apt-get update apt-get source --compile netrek-client-cow If you're on Ubuntu, let me know how it goes. Anyone got an x86_64 host willing to do builds? -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ _______________________________________________ netrek-dev mailing list netrek-dev at us.netrek.org http://mailman.us.netrek.org/mailman/listinfo/netrek-dev -- Be Yourself @ mail.com! Choose From 200+ Email Addresses Get a Free Account at www.mail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20080730/2fd33e0d/attachment-0001.htm From quozl at us.netrek.org Wed Jul 30 22:05:32 2008 From: quozl at us.netrek.org (James Cameron) Date: Thu, 31 Jul 2008 13:05:32 +1000 Subject: [netrek-dev] netrek-client-cow-3.2.6 released In-Reply-To: <20080730160911.698281158CC@ws1-7.us4.outblaze.com> References: <20080730160911.698281158CC@ws1-7.us4.outblaze.com> Message-ID: <20080731030532.GB6844@us.netrek.org> -ENOPATCH; On Wed, Jul 30, 2008 at 08:09:09AM -0800, . . wrote: > [... lots of irrelevant stuff ...] > socket.c: At top level: > socket.c:2652: error: conflicting types for sendUpdatePacket > socket.h:52: error: previous declaration of sendUpdatePacket was here Caused by your x86_64 build environment though, interesting. Here is the patch, apply and try again. Or "darcs pull". --- old-netrek-client-cow/socket.h 2008-07-31 12:56:07.000000000 +1000 +++ new-netrek-client-cow/socket.h 2008-07-31 12:56:07.000000000 +1000 @@ -49,7 +49,7 @@ // void handlePlyrLogin(struct plyr_login_spacket *packet, int sock); // void handleStats(struct stats_spacket *packet); // void handlePlyrInfo(struct plyr_info_spacket *packet); -void sendUpdatePacket(long speed); +void sendUpdatePacket(LONG speed); // void handlePlanetLoc(struct planet_loc_spacket *packet); // void handleReserved(struct reserved_spacket *packet, int sock); // void handleShipCap(struct ship_cap_spacket *packet); -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ From quozl at us.netrek.org Thu Jul 31 02:52:01 2008 From: quozl at us.netrek.org (James Cameron) Date: Thu, 31 Jul 2008 17:52:01 +1000 Subject: [netrek-dev] RFC: netrek-client-cow OpenVMS support removal Message-ID: <20080731075201.GA23510@us.netrek.org> The attached patch removes support for OpenVMS from COW. Anyone who plays Netrek on a currently running OpenVMS system is welcome to comment. (The code was added by me in COW 1.01 pl1 released Apr 25, 1994, and was refreshed in 3.00 pl0 released Feb 28, 1998. I'd forgotten it was there until I was reminded today, and I don't believe it should still be there unless there are active players.) -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: netrek-client-cow-remove-openvms-support.diff Type: text/x-diff Size: 43532 bytes Desc: not available Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20080731/7a8f8499/attachment-0001.diff -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20080731/7a8f8499/attachment-0001.pgp From msucka0xff at programmer.net Thu Jul 31 10:50:24 2008 From: msucka0xff at programmer.net (. .) Date: Thu, 31 Jul 2008 07:50:24 -0800 Subject: [netrek-dev] RFC: netrek-client-cow OpenVMS support removal Message-ID: <20080731155024.B639D1CE83B@ws1-6.us4.outblaze.com> will continue off list ----- Original Message ----- From: "James Cameron" To: netrek-dev at lists.netrek.org Subject: [netrek-dev] RFC: netrek-client-cow OpenVMS support removal Date: Thu, 31 Jul 2008 17:52:01 +1000 The attached patch removes support for OpenVMS from COW. Anyone who plays Netrek on a currently running OpenVMS system is welcome to comment. (The code was added by me in COW 1.01 pl1 released Apr 25, 1994, and was refreshed in 3.00 pl0 released Feb 28, 1998. I'd forgotten it was there until I was reminded today, and I don't believe it should still be there unless there are active players.) -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ << signature.asc >> _______________________________________________ netrek-dev mailing list netrek-dev at us.netrek.org http://mailman.us.netrek.org/mailman/listinfo/netrek-dev -- Be Yourself @ mail.com! Choose From 200+ Email Addresses Get a Free Account at www.mail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20080731/a0d571a3/attachment.htm