From David.Watson at team17.com Thu Feb 5 10:48:06 2004 From: David.Watson at team17.com (David Watson) Date: Wed Jan 12 00:50:51 2005 Subject: [Vanilla Devel] Player database problems Message-ID: <5.2.0.9.0.20040205161749.01cad230@mailgate.team17.com> Hi, I'm trying to get a Pre-T server going and I've a problem with it. On approx 28th Jan I grabbed the code from CVS and compiled it, I've got a running server that people can connect to (eurotwinks.netrek.org). I'm having some trouble connecting to the metaserver but after a little advice I think thats a config error at my end. The player database is broken however. When I add a new character the .players increases in size but on subsequent logins I have to give the password twice and the .players increases in size. the pledit util segfaults on the file. If I copy an old .players across from another server I can log in with existing characters and run pledit. New characters do not add properly and as soon as there is one in the database pledit will segfault. Any ideas? Cheers Dave _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From slagerni at msu.edu Thu Feb 5 11:54:17 2004 From: slagerni at msu.edu (Nicholas James Slager) Date: Wed Jan 12 00:50:51 2005 Subject: [Vanilla Devel] Re: Player database problems In-Reply-To: <5.2.0.9.0.20040205161749.01cad230@mailgate.team17.com> References: <5.2.0.9.0.20040205161749.01cad230@mailgate.team17.com> Message-ID: Well, somehow it's probably my fault. I'd guess it might have something to do with the fact that I didn't want to save stats with bots in the game. If you're looking to correct the problem I'd start looking there. I'd also see if having a real game would cause your players to save correctly. Sorry if I broke things :/ Nick David Watson writes: > > Hi, > I'm trying to get a Pre-T server going and I've a problem with it. On > approx 28th Jan I grabbed the code from CVS and compiled it, I've got a > running server that people can connect to (eurotwinks.netrek.org). I'm > having some trouble connecting to the metaserver but after a little advice > I think thats a config error at my end. > > The player database is broken however. When I add a new character the > .players increases in size but on subsequent logins I have to give the > password twice and the .players increases in size. > > the pledit util segfaults on the file. > > If I copy an old .players across from another server I can log in with > existing characters and run pledit. New characters do not add properly and > as soon as there is one in the database pledit will segfault. > > Any ideas? > > Cheers > Dave > > > _______________________________________________ > vanilla-devel mailing list > vanilla-devel@us.netrek.org > https://mailman.real-time.com/mailman/listinfo/vanilla-devel > _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From quozl at us.netrek.org Thu Feb 5 15:57:41 2004 From: quozl at us.netrek.org (James Cameron) Date: Wed Jan 12 00:50:51 2005 Subject: [Vanilla Devel] Re: Player database problems In-Reply-To: References: <5.2.0.9.0.20040205161749.01cad230@mailgate.team17.com> Message-ID: <20040205214949.GA27495@us.netrek.org> It might be my fault too! I was working on a method to have users created by a web server script rather than automatically created first time. Maybe my temporary changes found their way into CVS. I'll try the current CVS version to see whether it works the way it used to. -- James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/ _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From David.Watson at team17.com Fri Feb 6 05:13:10 2004 From: David.Watson at team17.com (David Watson) Date: Wed Jan 12 00:50:51 2005 Subject: [Vanilla Devel] Re: Player database problems In-Reply-To: References: <5.2.0.9.0.20040205161749.01cad230@mailgate.team17.com> <5.2.0.9.0.20040205161749.01cad230@mailgate.team17.com> Message-ID: <5.2.0.9.0.20040206105625.038a9ea8@mailgate.team17.com> Well I tried a normal game and got the same corruption of the database. I also don't seem to get solicitation of the metaservers (from iptables logging on that machine looking for outgoing traffic on 3521 (udp and tcp). In fact Ideally I would like bots to appear as players to attract new people to try that first, I guess I will have to look at the code but my programming is pretty feeble. Cheers Dave _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From quozl at us.netrek.org Fri Feb 6 06:37:10 2004 From: quozl at us.netrek.org (James Cameron) Date: Wed Jan 12 00:50:51 2005 Subject: [Vanilla Devel] Re: Player database problems In-Reply-To: <5.2.0.9.0.20040206105625.038a9ea8@mailgate.team17.com> References: <5.2.0.9.0.20040205161749.01cad230@mailgate.team17.com> <5.2.0.9.0.20040205161749.01cad230@mailgate.team17.com> <5.2.0.9.0.20040206105625.038a9ea8@mailgate.team17.com> Message-ID: <20040206123329.GA5076@us.netrek.org> I haven't yet looked at the database problem, (I've started!) but can you check that you've set up a .metaservers file? See the documentation file on how to do it. -- James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/ _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From slagerni at msu.edu Fri Feb 6 08:49:32 2004 From: slagerni at msu.edu (Nicholas James Slager) Date: Wed Jan 12 00:50:51 2005 Subject: [Vanilla Devel] Re: Player database problems In-Reply-To: <5.2.0.9.0.20040206105625.038a9ea8@mailgate.team17.com> References: <5.2.0.9.0.20040205161749.01cad230@mailgate.team17.com> <5.2.0.9.0.20040205161749.01cad230@mailgate.team17.com> <5.2.0.9.0.20040206105625.038a9ea8@mailgate.team17.com> Message-ID: The pre-t bots don't spawn until the first person enters the server. About a minute after the last person leaves the server the bots go away again. It shouldn't be too hard to keep the bots going instead of being killed. Your only issues would be to start the bots when the server is started or a geno happens and no one comes back. It's nice to hear that it probably wasn't me that broke the db ;) If James put the pre-t bots on contunuum too, I might have to start playing and working on my client again... Nick David Watson writes: > > Well I tried a normal game and got the same corruption of the database. I > also don't seem to get solicitation of the metaservers (from iptables > logging on that machine looking for outgoing traffic on 3521 (udp and > tcp). In fact Ideally I would like bots to appear as players to attract > new people to try that first, I guess I will have to look at the code but > my programming is pretty feeble. > > > Cheers > > Dave > > > _______________________________________________ > vanilla-devel mailing list > vanilla-devel@us.netrek.org > https://mailman.real-time.com/mailman/listinfo/vanilla-devel > _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From quozl at us.netrek.org Fri Feb 6 16:02:26 2004 From: quozl at us.netrek.org (James Cameron) Date: Wed Jan 12 00:50:51 2005 Subject: [Vanilla Devel] Re: Player database problems In-Reply-To: References: <5.2.0.9.0.20040205161749.01cad230@mailgate.team17.com> <5.2.0.9.0.20040205161749.01cad230@mailgate.team17.com> <5.2.0.9.0.20040206105625.038a9ea8@mailgate.team17.com> Message-ID: <20040206215359.GA22736@us.netrek.org> On Fri, Feb 06, 2004 at 09:39:56AM -0500, Nicholas James Slager wrote: > If James put the pre-t bots on contunuum too, I might have to start playing > and working on my client again... What's the effect, and where's the documentation on how to do it? I have no compuction about fiddling with the rules pre-t, if such fiddling increases the chances of t. -- James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/ _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From quozl at us.netrek.org Fri Feb 6 16:46:36 2004 From: quozl at us.netrek.org (James Cameron) Date: Wed Jan 12 00:50:51 2005 Subject: [Vanilla Devel] Re: Player database problems In-Reply-To: <5.2.0.9.0.20040206105625.038a9ea8@mailgate.team17.com> References: <5.2.0.9.0.20040205161749.01cad230@mailgate.team17.com> <5.2.0.9.0.20040205161749.01cad230@mailgate.team17.com> <5.2.0.9.0.20040206105625.038a9ea8@mailgate.team17.com> Message-ID: <20040206223051.GF22736@us.netrek.org> Check ERRORS for problems. ntserv/solicit.c is the Metaserver solicitation code. It is supposed to say if anything goes wrong, even DNS lookup failures. It uses UDP on destination port 3521. I'd use tcpdump rather than iptables myself. tcpdump -i eth0 -s 0 -x udp port 3521 -- James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/ _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From slagerni at msu.edu Sat Feb 7 10:24:02 2004 From: slagerni at msu.edu (Nicholas James Slager) Date: Wed Jan 12 00:50:51 2005 Subject: [Vanilla Devel] Re: Player database problems In-Reply-To: <20040206215359.GA22736@us.netrek.org> References: <5.2.0.9.0.20040205161749.01cad230@mailgate.team17.com> <5.2.0.9.0.20040205161749.01cad230@mailgate.team17.com> <5.2.0.9.0.20040206105625.038a9ea8@mailgate.team17.com> <20040206215359.GA22736@us.netrek.org> Message-ID: Turning on pre-t mode is as easy as turning it on in your .sysdef file. It's something like PRET=1. When turned on, bots will join the game to make a 4 on 4 game. As real people arive, bots will leave. Special rules for pre-t mode... - No stats are recorded during pre-t - The galaxy will reset when one team is up by 3 planets. This way the game should never be in a geno state which is discouraging for newbies. - Bots can be directed, although they are extreamly stupid. - If T is lost, the bots will come back in no more then 5 minutes from the time T was lost. - I'm probably forgetting some minor things. Pre-t is simply a way to give people something to do while hanging out waiting for T. It's certainly not supposed to be a replacement for real games, just a helper to get you to a real game. Turn it on, try it out. Ignore old crusty idiots that don't like the bots cause they're dumb. Nick James Cameron writes: > On Fri, Feb 06, 2004 at 09:39:56AM -0500, Nicholas James Slager wrote: >> If James put the pre-t bots on contunuum too, I might have to start playing >> and working on my client again... > > What's the effect, and where's the documentation on how to do it? > > I have no compuction about fiddling with the rules pre-t, if such > fiddling increases the chances of t. > > -- > James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/ > > _______________________________________________ > vanilla-devel mailing list > vanilla-devel@us.netrek.org > https://mailman.real-time.com/mailman/listinfo/vanilla-devel > _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From vanillatrek at yahoo.com Fri Feb 13 12:01:12 2004 From: vanillatrek at yahoo.com (Zach) Date: Wed Jan 12 00:50:52 2005 Subject: [Vanilla Devel] Re: Player database problems In-Reply-To: Message-ID: <20040213174105.17015.qmail@web21101.mail.yahoo.com> I agree. We have a new influx of newbies thanks to Joe's marketing efforts and we should capitalize on this. Pre-T bots on a dedicated newbie server will facilitate greater retention of this new players IMHO. Nick was your pre-T code ever released? Zach --- Nicholas James Slager wrote: > Turning on pre-t mode is as easy as turning it on in your > .sysdef file. It's > something like PRET=1. When turned on, bots will join the > game to make a 4 > on 4 game. As real people arive, bots will leave. __________________________________ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From slagerni at msu.edu Fri Feb 13 14:14:33 2004 From: slagerni at msu.edu (Nicholas James Slager) Date: Wed Jan 12 00:50:52 2005 Subject: [Vanilla Devel] Re: Player database problems In-Reply-To: <20040213174105.17015.qmail@web21101.mail.yahoo.com> References: <20040213174105.17015.qmail@web21101.mail.yahoo.com> Message-ID: Of course. It's in the main CVS branch. It should be turned on on all servers. There's no reason not to. Nick Zach writes: > I agree. We have a new influx of newbies thanks to Joe's > marketing efforts and we should capitalize on this. Pre-T > bots on a dedicated newbie server will facilitate greater > retention of this new players IMHO. Nick was your pre-T > code ever released? > > Zach > > --- Nicholas James Slager wrote: >> Turning on pre-t mode is as easy as turning it on in your >> .sysdef file. It's >> something like PRET=1. When turned on, bots will join the >> game to make a 4 >> on 4 game. As real people arive, bots will leave. > > > __________________________________ > Do you Yahoo!? > Yahoo! Finance: Get your refund fast by filing online. > http://taxes.yahoo.com/filing.html > > _______________________________________________ > vanilla-devel mailing list > vanilla-devel@us.netrek.org > https://mailman.real-time.com/mailman/listinfo/vanilla-devel > _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From jeffno at charter.net Fri Feb 13 14:15:57 2004 From: jeffno at charter.net (Jeff Nowakowski) Date: Wed Jan 12 00:50:52 2005 Subject: [Vanilla Devel] Re: Player database problems References: <20040213174105.17015.qmail@web21101.mail.yahoo.com> Message-ID: <001401c3f26b$0ee5ceb0$6400a8c0@jeffhymajrfplv> I seem to recall you made a big stink about pre-t bots not being the default. -Jeff ----- Original Message ----- From: "Zach" To: "Vanilla Netrek Development Mailing List" Sent: Friday, February 13, 2004 5:41 PM Subject: Re: [Vanilla Devel] Re: Player database problems > I agree. We have a new influx of newbies thanks to Joe's > marketing efforts and we should capitalize on this. Pre-T > bots on a dedicated newbie server will facilitate greater > retention of this new players IMHO. Nick was your pre-T > code ever released? > > Zach > > --- Nicholas James Slager wrote: > > Turning on pre-t mode is as easy as turning it on in your > > .sysdef file. It's > > something like PRET=1. When turned on, bots will join the > > game to make a 4 > > on 4 game. As real people arive, bots will leave. > > > __________________________________ > Do you Yahoo!? > Yahoo! Finance: Get your refund fast by filing online. > http://taxes.yahoo.com/filing.html > > _______________________________________________ > vanilla-devel mailing list > vanilla-devel@us.netrek.org > https://mailman.real-time.com/mailman/listinfo/vanilla-devel _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From vanilla-devel at us.netrek.org Fri Feb 13 20:18:46 2004 From: vanilla-devel at us.netrek.org (Vanilla CVS Development) Date: Wed Jan 12 00:50:53 2005 Subject: [Vanilla Devel] CVS update: Vanilla/tools Message-ID: <200402140208.i1E28pP04534@swashbuckler.real-time.com> Date: Friday February 13, 2004 @ 20:08 Author: cameron Update of /home/netrek/cvsroot/Vanilla/tools In directory swashbuckler.real-time.com:/var/tmp/cvs-serv4531 Modified Files: xtkill.c Log Message: **************************************** Index: Vanilla/tools/xtkill.c diff -u Vanilla/tools/xtkill.c:1.9 Vanilla/tools/xtkill.c:1.10 --- Vanilla/tools/xtkill.c:1.9 Tue May 21 01:17:10 2002 +++ Vanilla/tools/xtkill.c Fri Feb 13 20:08:50 2004 @@ -140,7 +140,21 @@ case 'd': getship(&players[player].p_ship, DESTROYER); break; case 's': getship(&players[player].p_ship, SCOUT); break; case 'o': getship(&players[player].p_ship, STARBASE); break; - case 'A': getship(&players[player].p_ship, ATT); break; + case 'A': + getship(&players[player].p_ship, ATT); + players[player].p_ship.s_width = 20; + players[player].p_ship.s_height = 20; + break; + case 'g': + getship(&players[player].p_ship, SCOUT); + players[player].p_ship.s_torpdamage = 1; + players[player].p_ship.s_torpfuse = 8; + players[player].p_ship.s_phaserdamage = 1; + players[player].p_ship.s_plasmadamage = 1; + players[player].p_ship.s_plasmaspeed = 1; + players[player].p_ship.s_plasmaturns = 1; + players[player].p_ship.s_maxshield = 750; + break; default: printf("Valid ship types: abcdsoA.\n"); exit(1); @@ -151,6 +165,7 @@ players[player].p_wtemp = 0; players[player].p_etemp = 0; players[player].p_fuel = players[player].p_ship.s_maxfuel; + if (argv[2][1] == 'o') players[player].p_flags |= PFDOCKOK; break; case 'p': /* puck? */ players[player].p_ship.s_tractstr = 1; _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From vanilla-devel at us.netrek.org Fri Feb 13 21:40:54 2004 From: vanilla-devel at us.netrek.org (Vanilla CVS Development) Date: Wed Jan 12 00:50:53 2005 Subject: [Vanilla Devel] CVS update: Vanilla/gum Message-ID: <200402140333.i1E3XEQ04587@swashbuckler.real-time.com> Date: Friday February 13, 2004 @ 21:33 Author: cameron Update of /home/netrek/cvsroot/Vanilla/gum In directory swashbuckler.real-time.com:/var/tmp/cvs-serv4584 Modified Files: Makefile.am Makefile.in Log Message: add DESTDIR support **************************************** Index: Vanilla/gum/Makefile.am diff -u Vanilla/gum/Makefile.am:1.11 Vanilla/gum/Makefile.am:1.12 --- Vanilla/gum/Makefile.am:1.11 Tue May 1 21:00:18 2001 +++ Vanilla/gum/Makefile.am Fri Feb 13 21:33:14 2004 @@ -19,8 +19,8 @@ install-data-local: test -d ${srcdir}/pixmaps \ - && install -d -m 0755 $(pkgdatadir)/pixmaps \ - && install -m 0644 ${srcdir}/pixmaps/*.xpm $(pkgdatadir)/pixmaps + && install -d -m 0755 $(DESTDIR)$(pkgdatadir)/pixmaps \ + && install -m 0644 ${srcdir}/pixmaps/*.xpm $(DESTDIR)$(pkgdatadir)/pixmaps dist-hook: test -d pixmaps \ Index: Vanilla/gum/Makefile.in diff -u Vanilla/gum/Makefile.in:1.15 Vanilla/gum/Makefile.in:1.16 --- Vanilla/gum/Makefile.in:1.15 Tue May 8 06:48:53 2001 +++ Vanilla/gum/Makefile.in Fri Feb 13 21:33:14 2004 @@ -440,8 +440,8 @@ install-data-local: test -d ${srcdir}/pixmaps \ - && install -d -m 0755 $(pkgdatadir)/pixmaps \ - && install -m 0644 ${srcdir}/pixmaps/*.xpm $(pkgdatadir)/pixmaps + && install -d -m 0755 $(DESTDIR)$(pkgdatadir)/pixmaps \ + && install -m 0644 ${srcdir}/pixmaps/*.xpm $(DESTDIR)$(pkgdatadir)/pixmaps dist-hook: test -d pixmaps \ _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From vanilla-devel at us.netrek.org Fri Feb 13 22:13:31 2004 From: vanilla-devel at us.netrek.org (Vanilla CVS Development) Date: Wed Jan 12 00:50:53 2005 Subject: [Vanilla Devel] CVS update: Vanilla/robotd Message-ID: <200402140402.i1E42ml04607@swashbuckler.real-time.com> Date: Friday February 13, 2004 @ 22:02 Author: cameron Update of /home/netrek/cvsroot/Vanilla/robotd In directory swashbuckler.real-time.com:/var/tmp/cvs-serv4604/robotd Modified Files: Makefile.in Log Message: fix location of robot on install **************************************** Index: Vanilla/robotd/Makefile.in diff -u Vanilla/robotd/Makefile.in:1.3 Vanilla/robotd/Makefile.in:1.4 --- Vanilla/robotd/Makefile.in:1.3 Wed Sep 24 05:08:30 2003 +++ Vanilla/robotd/Makefile.in Fri Feb 13 22:02:48 2004 @@ -107,9 +107,9 @@ $(CC) $(CFLAGS) ${LDFLAGS} -o robot $(R_OBJS) $(INPUT) $(LIBS) $(EXTRALIBS) install: robot - -mkdir $(DESTDIR)$(LIBDIR) - cp robot $(DESTDIR)$(LIBDIR)/robot - if [ -d ${srcdir}/og -a `ls -a ${srcdir}/og | wc -l ` != 2 ]; then cp ${srcdir}/og/* $(DESTDIR)$(LIBDIR); fi + -mkdir $(DESTDIR)$(LIBDIR)/og + cp robot $(DESTDIR)$(LIBDIR)/og/robot + if [ -d ${srcdir}/og -a `ls -a ${srcdir}/og | wc -l ` != 2 ]; then cp ${srcdir}/og/* $(DESTDIR)$(LIBDIR)/og/; fi _robot: $(R_OBJS) $(INPUT) _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From vanilla-devel at us.netrek.org Fri Feb 13 22:13:42 2004 From: vanilla-devel at us.netrek.org (Vanilla CVS Development) Date: Wed Jan 12 00:50:53 2005 Subject: [Vanilla Devel] CVS update: Vanilla/gum Message-ID: <200402140403.i1E43b504620@swashbuckler.real-time.com> Date: Friday February 13, 2004 @ 22:03 Author: cameron Update of /home/netrek/cvsroot/Vanilla/gum In directory swashbuckler.real-time.com:/var/tmp/cvs-serv4612/gum Modified Files: ChangeLog Log Message: **************************************** Index: Vanilla/gum/ChangeLog diff -u Vanilla/gum/ChangeLog:1.11 Vanilla/gum/ChangeLog:1.12 --- Vanilla/gum/ChangeLog:1.11 Tue May 8 06:48:53 2001 +++ Vanilla/gum/ChangeLog Fri Feb 13 22:03:37 2004 @@ -1,3 +1,8 @@ +Sat Feb 14 15:00:16 2004 James Cameron + + * Makefile.am (install-data-local): add DESTDIR support for + packaging. + Tue May 8 22:35:41 2001 Benjamin `Quisar' Lerman * gum.xml: add newbie flag. [rebuild using glade 0.5.5 by Quozl] @@ -76,6 +81,6 @@ * signals.c (on_About_activate): revise about screen to show who to complain to. - $Id: ChangeLog,v 1.11 2001/05/08 11:48:53 cameron Exp $ + $Id: ChangeLog,v 1.12 2004/02/14 04:03:37 cameron Exp $ _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From vanilla-devel at us.netrek.org Fri Feb 13 22:13:55 2004 From: vanilla-devel at us.netrek.org (Vanilla CVS Development) Date: Wed Jan 12 00:50:53 2005 Subject: [Vanilla Devel] CVS update: Vanilla Message-ID: <200402140403.i1E43bs04615@swashbuckler.real-time.com> Date: Friday February 13, 2004 @ 22:03 Author: cameron Update of /home/netrek/cvsroot/Vanilla In directory swashbuckler.real-time.com:/var/tmp/cvs-serv4612 Modified Files: ChangeLog Log Message: **************************************** Index: Vanilla/ChangeLog diff -u Vanilla/ChangeLog:1.146 Vanilla/ChangeLog:1.147 --- Vanilla/ChangeLog:1.146 Wed Jan 7 20:42:20 2004 +++ Vanilla/ChangeLog Fri Feb 13 22:03:37 2004 @@ -1,3 +1,8 @@ +Sat Feb 14 14:59:37 2004 James Cameron + + * robotd/Makefile.in (install): place robot where pret and other + code expects to find it. + Wed Jan 7 18:30:36 2004 Carlos Y. Villalpando * robots/puck.c (main): Added items for makeing sure puck robot @@ -1498,4 +1503,4 @@ update_sys_defaults in updateMessages to a more appropriate location - updateClient in socket.c. - $Id: ChangeLog,v 1.146 2004/01/08 02:42:20 unbelver Exp $ + $Id: ChangeLog,v 1.147 2004/02/14 04:03:37 cameron Exp $ _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From vanilla-devel at us.netrek.org Fri Feb 13 23:35:48 2004 From: vanilla-devel at us.netrek.org (Vanilla CVS Development) Date: Wed Jan 12 00:50:53 2005 Subject: [Vanilla Devel] CVS update: Vanilla/gum Message-ID: <200402140528.i1E5SEb04662@swashbuckler.real-time.com> Date: Friday February 13, 2004 @ 23:28 Author: cameron Update of /home/netrek/cvsroot/Vanilla/gum In directory swashbuckler.real-time.com:/var/tmp/cvs-serv4659 Modified Files: ChangeLog gum.xml main.c support.c Log Message: add pret support to server admin gui (main.c and support.c are generated code from glade) **************************************** Index: Vanilla/gum/ChangeLog diff -u Vanilla/gum/ChangeLog:1.12 Vanilla/gum/ChangeLog:1.13 --- Vanilla/gum/ChangeLog:1.12 Fri Feb 13 22:03:37 2004 +++ Vanilla/gum/ChangeLog Fri Feb 13 23:28:14 2004 @@ -1,3 +1,8 @@ +Sat Feb 14 16:24:06 2004 James Cameron + + * gum.xml: add PRET support following untracked change to + sysdefaults.h. + Sat Feb 14 15:00:16 2004 James Cameron * Makefile.am (install-data-local): add DESTDIR support for @@ -81,6 +86,6 @@ * signals.c (on_About_activate): revise about screen to show who to complain to. - $Id: ChangeLog,v 1.12 2004/02/14 04:03:37 cameron Exp $ + $Id: ChangeLog,v 1.13 2004/02/14 05:28:14 cameron Exp $ Index: Vanilla/gum/gum.xml diff -u Vanilla/gum/gum.xml:1.12 Vanilla/gum/gum.xml:1.13 --- Vanilla/gum/gum.xml:1.12 Thu May 10 20:45:59 2001 +++ Vanilla/gum/gum.xml Fri Feb 13 23:28:14 2004 @@ -10,17 +10,11 @@ C False False - False False - True - True - True main.c main.h signals.c signals.h - support.c - support.h @@ -699,6 +693,7 @@ Tue, 09 Feb 1999 23:22:27 GMT + GTK_RELIEF_NORMAL @@ -712,6 +707,7 @@ Wed, 10 Feb 1999 13:01:48 GMT + GTK_RELIEF_NORMAL @@ -726,6 +722,7 @@ Tue, 09 Feb 1999 23:22:40 GMT + GTK_RELIEF_NORMAL @@ -740,6 +737,7 @@ Tue, 09 Feb 1999 23:22:55 GMT + GTK_RELIEF_NORMAL @@ -756,7 +754,7 @@ GtkLabel label139 - + GTK_JUSTIFY_CENTER False 0.5 @@ -826,6 +824,7 @@ Tue, 09 Feb 1999 23:23:58 GMT + GTK_RELIEF_NORMAL @@ -840,6 +839,7 @@ Tue, 09 Feb 1999 23:24:23 GMT + GTK_RELIEF_NORMAL @@ -854,6 +854,7 @@ Tue, 09 Feb 1999 23:24:32 GMT + GTK_RELIEF_NORMAL @@ -868,6 +869,7 @@ Tue, 09 Feb 1999 23:24:44 GMT + GTK_RELIEF_NORMAL @@ -1840,6 +1842,7 @@ Tue, 25 May 1999 06:55:47 GMT + GTK_RELIEF_NORMAL @@ -1852,6 +1855,7 @@ Tue, 25 May 1999 06:55:53 GMT + GTK_RELIEF_NORMAL @@ -1864,6 +1868,7 @@ Tue, 25 May 1999 06:56:10 GMT + GTK_RELIEF_NORMAL @@ -1876,6 +1881,7 @@ Tue, 25 May 1999 06:56:19 GMT + GTK_RELIEF_NORMAL @@ -2048,6 +2054,7 @@ Thu, 14 Jan 1999 16:22:13 GMT + GTK_RELIEF_NORMAL 0 True @@ -3045,6 +3052,7 @@ WEAPONS_PLASMA True + GTK_RELIEF_NORMAL True 0 @@ -3058,6 +3066,7 @@ WEAPONS_TRACTOR True + GTK_RELIEF_NORMAL True 0 @@ -5900,9 +5909,9 @@ GtkTable - table7 + table16 6 - 4 + 5 2 False 6 @@ -5910,8 +5919,8 @@ GtkLabel - label126 - @@ -7716,6 +7836,7 @@ Thu, 14 Jan 1999 15:51:59 GMT + GTK_RELIEF_NORMAL @@ -7751,6 +7872,7 @@ Thu, 14 Jan 1999 15:51:07 GMT + GTK_RELIEF_NORMAL @@ -7765,6 +7887,7 @@ Thu, 14 Jan 1999 15:50:59 GMT + GTK_RELIEF_NORMAL Index: Vanilla/gum/main.c diff -u Vanilla/gum/main.c:1.11 Vanilla/gum/main.c:1.12 --- Vanilla/gum/main.c:1.11 Thu May 10 20:45:59 2001 +++ Vanilla/gum/main.c Fri Feb 13 23:28:14 2004 @@ -353,18 +353,6 @@ GtkWidget *MAX_POP; GtkWidget *label116; GtkWidget *label17; - GtkWidget *table7; - GtkWidget *label126; - GtkWidget *BASEPRACTICE_LABEL; - GtkWidget *ROBOTHOST_LABEL; - GtkWidget *hbox42; - GSList *BASEPRACTICE_group = NULL; - GtkWidget *BASEPRACTICE_0; - GtkWidget *BASEPRACTICE_1; - GtkWidget *hbox43; - GtkWidget *ROBOTHOST; - GtkWidget *label127; - GtkWidget *label51; GtkWidget *table16; GtkWidget *label1395; GtkWidget *NEWBIE_LABEL; @@ -373,16 +361,13 @@ GtkWidget *NEWBIE_0; GtkWidget *NEWBIE_1; GtkWidget *label1397; + GtkWidget *label1398; + GtkWidget *PRET_LABEL; + GtkWidget *hbox59; + GSList *PRET_group = NULL; + GtkWidget *PRET_0; + GtkWidget *PRET_1; GtkWidget *label1392; - GtkWidget *table8; - GtkWidget *label128; - GtkWidget *HOCKEY_LABEL; - GtkWidget *hbox44; - GSList *HOCKEY_group = NULL; - GtkWidget *HOCKEY_0; - GtkWidget *HOCKEY_1; - GtkWidget *label131; - GtkWidget *label54; GtkWidget *table9; GtkWidget *hbox45; GSList *INL_group = NULL; @@ -397,6 +382,27 @@ GtkWidget *INL_RECORD_0; GtkWidget *INL_RECORD_1; GtkWidget *INL_NOTEBOOK_LABEL; + GtkWidget *table7; + GtkWidget *label126; + GtkWidget *BASEPRACTICE_LABEL; + GtkWidget *ROBOTHOST_LABEL; + GtkWidget *hbox42; + GSList *BASEPRACTICE_group = NULL; + GtkWidget *BASEPRACTICE_0; + GtkWidget *BASEPRACTICE_1; + GtkWidget *hbox43; + GtkWidget *ROBOTHOST; + GtkWidget *label127; + GtkWidget *label51; + GtkWidget *table8; + GtkWidget *label128; + GtkWidget *HOCKEY_LABEL; + GtkWidget *hbox44; + GSList *HOCKEY_group = NULL; + GtkWidget *HOCKEY_0; + GtkWidget *HOCKEY_1; + GtkWidget *label131; + GtkWidget *label54; GtkWidget *table10; GtkWidget *label124; GtkWidget *DOGFIGHT_LABEL; @@ -828,7 +834,7 @@ gtk_widget_show (hseparator2); gtk_box_pack_start (GTK_BOX (vbox2), hseparator2, FALSE, TRUE, 6); - label139 = gtk_label_new ("Listener Process Commands"); + label139 = gtk_label_new ("netrekd - Listener Process Commands"); gtk_widget_ref (label139); gtk_object_set_data_full (GTK_OBJECT (gum), "label139", label139, (GtkDestroyNotify) gtk_widget_unref); @@ -3283,105 +3289,7 @@ gtk_widget_show (label17); gtk_notebook_set_tab_label (GTK_NOTEBOOK (notebook1), gtk_notebook_get_nth_page (GTK_NOTEBOOK (notebook1), 6), label17); - table7 = gtk_table_new (4, 2, FALSE); - gtk_widget_ref (table7); - gtk_object_set_data_full (GTK_OBJECT (gum), "table7", table7, - (GtkDestroyNotify) gtk_widget_unref); - gtk_widget_show (table7); - gtk_container_add (GTK_CONTAINER (notebook1), table7); - gtk_container_set_border_width (GTK_CONTAINER (table7), 6); - gtk_table_set_row_spacings (GTK_TABLE (table7), 6); - gtk_table_set_col_spacings (GTK_TABLE (table7), 6); - - label126 = gtk_label_new ("Base Practice Mode Settings\n"); - gtk_widget_ref (label126); - gtk_object_set_data_full (GTK_OBJECT (gum), "label126", label126, - (GtkDestroyNotify) gtk_widget_unref); - gtk_widget_show (label126); - gtk_table_attach (GTK_TABLE (table7), label126, 0, 2, 0, 1, - (GtkAttachOptions) (GTK_EXPAND | GTK_FILL), - (GtkAttachOptions) (GTK_FILL), 0, 0); - - BASEPRACTICE_LABEL = gtk_label_new ("BASEPRACTICE:"); - gtk_widget_ref (BASEPRACTICE_LABEL); - gtk_object_set_data_full (GTK_OBJECT (gum), "BASEPRACTICE_LABEL", BASEPRACTICE_LABEL, - (GtkDestroyNotify) gtk_widget_unref); - gtk_widget_show (BASEPRACTICE_LABEL); - gtk_table_attach (GTK_TABLE (table7), BASEPRACTICE_LABEL, 0, 1, 1, 2, - (GtkAttachOptions) (GTK_FILL), - (GtkAttachOptions) (GTK_FILL), 0, 0); - gtk_misc_set_alignment (GTK_MISC (BASEPRACTICE_LABEL), 1, 0.5); - gtk_misc_set_padding (GTK_MISC (BASEPRACTICE_LABEL), 10, 0); - - ROBOTHOST_LABEL = gtk_label_new ("ROBOTHOST:"); - gtk_widget_ref (ROBOTHOST_LABEL); - gtk_object_set_data_full (GTK_OBJECT (gum), "ROBOTHOST_LABEL", ROBOTHOST_LABEL, - (GtkDestroyNotify) gtk_widget_unref); - gtk_widget_show (ROBOTHOST_LABEL); - gtk_table_attach (GTK_TABLE (table7), ROBOTHOST_LABEL, 0, 1, 2, 3, - (GtkAttachOptions) (GTK_FILL), - (GtkAttachOptions) (GTK_FILL), 0, 0); - gtk_misc_set_alignment (GTK_MISC (ROBOTHOST_LABEL), 1, 0.5); - gtk_misc_set_padding (GTK_MISC (ROBOTHOST_LABEL), 10, 0); - - hbox42 = gtk_hbox_new (FALSE, 0); - gtk_widget_ref (hbox42); - gtk_object_set_data_full (GTK_OBJECT (gum), "hbox42", hbox42, - (GtkDestroyNotify) gtk_widget_unref); - gtk_widget_show (hbox42); - gtk_table_attach (GTK_TABLE (table7), hbox42, 1, 2, 1, 2, - (GtkAttachOptions) (GTK_FILL), - (GtkAttachOptions) (GTK_FILL), 0, 0); - - BASEPRACTICE_0 = gtk_radio_button_new_with_label (BASEPRACTICE_group, "No"); - BASEPRACTICE_group = gtk_radio_button_group (GTK_RADIO_BUTTON (BASEPRACTICE_0)); - gtk_widget_ref (BASEPRACTICE_0); - gtk_object_set_data_full (GTK_OBJECT (gum), "BASEPRACTICE_0", BASEPRACTICE_0, - (GtkDestroyNotify) gtk_widget_unref); - gtk_widget_show (BASEPRACTICE_0); - gtk_box_pack_start (GTK_BOX (hbox42), BASEPRACTICE_0, FALSE, FALSE, 0); - - BASEPRACTICE_1 = gtk_radio_button_new_with_label (BASEPRACTICE_group, "Yes"); - BASEPRACTICE_group = gtk_radio_button_group (GTK_RADIO_BUTTON (BASEPRACTICE_1)); - gtk_widget_ref (BASEPRACTICE_1); - gtk_object_set_data_full (GTK_OBJECT (gum), "BASEPRACTICE_1", BASEPRACTICE_1, - (GtkDestroyNotify) gtk_widget_unref); - gtk_widget_show (BASEPRACTICE_1); - gtk_box_pack_start (GTK_BOX (hbox42), BASEPRACTICE_1, FALSE, FALSE, 0); - - hbox43 = gtk_hbox_new (FALSE, 0); - gtk_widget_ref (hbox43); - gtk_object_set_data_full (GTK_OBJECT (gum), "hbox43", hbox43, - (GtkDestroyNotify) gtk_widget_unref); - gtk_widget_show (hbox43); - gtk_table_attach (GTK_TABLE (table7), hbox43, 1, 2, 2, 3, - (GtkAttachOptions) (GTK_FILL), - (GtkAttachOptions) (GTK_FILL), 0, 0); - - ROBOTHOST = gtk_entry_new (); - gtk_widget_ref (ROBOTHOST); - gtk_object_set_data_full (GTK_OBJECT (gum), "ROBOTHOST", ROBOTHOST, - (GtkDestroyNotify) gtk_widget_unref); - gtk_widget_show (ROBOTHOST); - gtk_box_pack_start (GTK_BOX (hbox43), ROBOTHOST, TRUE, TRUE, 0); - - label127 = gtk_label_new (""); - gtk_widget_ref (label127); - gtk_object_set_data_full (GTK_OBJECT (gum), "label127", label127, - (GtkDestroyNotify) gtk_widget_unref); - gtk_widget_show (label127); - gtk_table_attach (GTK_TABLE (table7), label127, 0, 2, 3, 4, - (GtkAttachOptions) (GTK_FILL), - (GtkAttachOptions) (GTK_EXPAND | GTK_FILL), 0, 0); - - label51 = gtk_label_new ("Base Practice"); - gtk_widget_ref (label51); - gtk_object_set_data_full (GTK_OBJECT (gum), "label51", label51, - (GtkDestroyNotify) gtk_widget_unref); - gtk_widget_show (label51); - gtk_notebook_set_tab_label (GTK_NOTEBOOK (notebook1), gtk_notebook_get_nth_page (GTK_NOTEBOOK (notebook1), 7), label51); - - table16 = gtk_table_new (3, 2, FALSE); + table16 = gtk_table_new (5, 2, FALSE); gtk_widget_ref (table16); gtk_object_set_data_full (GTK_OBJECT (gum), "table16", table16, (GtkDestroyNotify) gtk_widget_unref); @@ -3441,87 +3349,61 @@ gtk_object_set_data_full (GTK_OBJECT (gum), "label1397", label1397, (GtkDestroyNotify) gtk_widget_unref); gtk_widget_show (label1397); - gtk_table_attach (GTK_TABLE (table16), label1397, 0, 2, 2, 3, + gtk_table_attach (GTK_TABLE (table16), label1397, 0, 2, 4, 5, (GtkAttachOptions) (GTK_EXPAND | GTK_FILL), (GtkAttachOptions) (GTK_EXPAND | GTK_FILL), 0, 0); - label1392 = gtk_label_new ("Newbie"); - gtk_widget_ref (label1392); - gtk_object_set_data_full (GTK_OBJECT (gum), "label1392", label1392, - (GtkDestroyNotify) gtk_widget_unref); - gtk_widget_show (label1392); - gtk_notebook_set_tab_label (GTK_NOTEBOOK (notebook1), gtk_notebook_get_nth_page (GTK_NOTEBOOK (notebook1), 8), label1392); - - table8 = gtk_table_new (3, 2, FALSE); - gtk_widget_ref (table8); - gtk_object_set_data_full (GTK_OBJECT (gum), "table8", table8, + label1398 = gtk_label_new ("Pre-T-mode Entertainment Settings\n"); + gtk_widget_ref (label1398); + gtk_object_set_data_full (GTK_OBJECT (gum), "label1398", label1398, (GtkDestroyNotify) gtk_widget_unref); - gtk_widget_show (table8); - gtk_container_add (GTK_CONTAINER (notebook1), table8); - gtk_container_set_border_width (GTK_CONTAINER (table8), 6); - gtk_table_set_row_spacings (GTK_TABLE (table8), 6); - gtk_table_set_col_spacings (GTK_TABLE (table8), 6); - - label128 = gtk_label_new ("Hockey Mode Settings\n"); - gtk_widget_ref (label128); - gtk_object_set_data_full (GTK_OBJECT (gum), "label128", label128, - (GtkDestroyNotify) gtk_widget_unref); - gtk_widget_show (label128); - gtk_table_attach (GTK_TABLE (table8), label128, 0, 2, 0, 1, - (GtkAttachOptions) (GTK_EXPAND | GTK_FILL), - (GtkAttachOptions) (GTK_FILL), 0, 0); + gtk_widget_show (label1398); + gtk_table_attach (GTK_TABLE (table16), label1398, 0, 2, 2, 3, + (GtkAttachOptions) (GTK_FILL), + (GtkAttachOptions) (0), 0, 0); - HOCKEY_LABEL = gtk_label_new ("HOCKEY:"); - gtk_widget_ref (HOCKEY_LABEL); - gtk_object_set_data_full (GTK_OBJECT (gum), "HOCKEY_LABEL", HOCKEY_LABEL, + PRET_LABEL = gtk_label_new ("PRET:"); + gtk_widget_ref (PRET_LABEL); + gtk_object_set_data_full (GTK_OBJECT (gum), "PRET_LABEL", PRET_LABEL, (GtkDestroyNotify) gtk_widget_unref); - gtk_widget_show (HOCKEY_LABEL); - gtk_table_attach (GTK_TABLE (table8), HOCKEY_LABEL, 0, 1, 1, 2, + gtk_widget_show (PRET_LABEL); + gtk_table_attach (GTK_TABLE (table16), PRET_LABEL, 0, 1, 3, 4, (GtkAttachOptions) (GTK_FILL), - (GtkAttachOptions) (GTK_FILL), 0, 0); - gtk_misc_set_alignment (GTK_MISC (HOCKEY_LABEL), 1, 0.5); - gtk_misc_set_padding (GTK_MISC (HOCKEY_LABEL), 10, 0); + (GtkAttachOptions) (0), 0, 0); + gtk_misc_set_alignment (GTK_MISC (PRET_LABEL), 1, 0.5); + gtk_misc_set_padding (GTK_MISC (PRET_LABEL), 10, 0); - hbox44 = gtk_hbox_new (FALSE, 0); - gtk_widget_ref (hbox44); - gtk_object_set_data_full (GTK_OBJECT (gum), "hbox44", hbox44, + hbox59 = gtk_hbox_new (FALSE, 0); + gtk_widget_ref (hbox59); + gtk_object_set_data_full (GTK_OBJECT (gum), "hbox59", hbox59, (GtkDestroyNotify) gtk_widget_unref); - gtk_widget_show (hbox44); - gtk_table_attach (GTK_TABLE (table8), hbox44, 1, 2, 1, 2, + gtk_widget_show (hbox59); + gtk_table_attach (GTK_TABLE (table16), hbox59, 1, 2, 3, 4, (GtkAttachOptions) (GTK_FILL), (GtkAttachOptions) (GTK_FILL), 0, 0); - HOCKEY_0 = gtk_radio_button_new_with_label (HOCKEY_group, "No"); - HOCKEY_group = gtk_radio_button_group (GTK_RADIO_BUTTON (HOCKEY_0)); - gtk_widget_ref (HOCKEY_0); - gtk_object_set_data_full (GTK_OBJECT (gum), "HOCKEY_0", HOCKEY_0, - (GtkDestroyNotify) gtk_widget_unref); - gtk_widget_show (HOCKEY_0); - gtk_box_pack_start (GTK_BOX (hbox44), HOCKEY_0, FALSE, FALSE, 0); - - HOCKEY_1 = gtk_radio_button_new_with_label (HOCKEY_group, "Yes"); - HOCKEY_group = gtk_radio_button_group (GTK_RADIO_BUTTON (HOCKEY_1)); - gtk_widget_ref (HOCKEY_1); - gtk_object_set_data_full (GTK_OBJECT (gum), "HOCKEY_1", HOCKEY_1, + PRET_0 = gtk_radio_button_new_with_label (PRET_group, "No"); + PRET_group = gtk_radio_button_group (GTK_RADIO_BUTTON (PRET_0)); + gtk_widget_ref (PRET_0); + gtk_object_set_data_full (GTK_OBJECT (gum), "PRET_0", PRET_0, (GtkDestroyNotify) gtk_widget_unref); - gtk_widget_show (HOCKEY_1); - gtk_box_pack_start (GTK_BOX (hbox44), HOCKEY_1, FALSE, FALSE, 0); + gtk_widget_show (PRET_0); + gtk_box_pack_start (GTK_BOX (hbox59), PRET_0, FALSE, FALSE, 0); - label131 = gtk_label_new (""); - gtk_widget_ref (label131); - gtk_object_set_data_full (GTK_OBJECT (gum), "label131", label131, + PRET_1 = gtk_radio_button_new_with_label (PRET_group, "Yes"); + PRET_group = gtk_radio_button_group (GTK_RADIO_BUTTON (PRET_1)); + gtk_widget_ref (PRET_1); + gtk_object_set_data_full (GTK_OBJECT (gum), "PRET_1", PRET_1, (GtkDestroyNotify) gtk_widget_unref); - gtk_widget_show (label131); - gtk_table_attach (GTK_TABLE (table8), label131, 0, 2, 2, 3, - (GtkAttachOptions) (GTK_EXPAND | GTK_FILL), - (GtkAttachOptions) (GTK_EXPAND | GTK_FILL), 0, 0); + gtk_widget_show (PRET_1); + gtk_box_pack_start (GTK_BOX (hbox59), PRET_1, FALSE, FALSE, 0); - label54 = gtk_label_new ("Hockey"); - gtk_widget_ref (label54); - gtk_object_set_data_full (GTK_OBJECT (gum), "label54", label54, + label1392 = gtk_label_new ("Robots"); + gtk_widget_ref (label1392); + gtk_object_set_data_full (GTK_OBJECT (gum), "label1392", label1392, (GtkDestroyNotify) gtk_widget_unref); - gtk_widget_show (label54); - gtk_notebook_set_tab_label (GTK_NOTEBOOK (notebook1), gtk_notebook_get_nth_page (GTK_NOTEBOOK (notebook1), 9), label54); + gtk_widget_show (label1392); + gtk_notebook_set_tab_label (GTK_NOTEBOOK (notebook1), gtk_notebook_get_nth_page (GTK_NOTEBOOK (notebook1), 7), label1392); table9 = gtk_table_new (4, 2, FALSE); gtk_widget_ref (table9); @@ -3630,7 +3512,176 @@ gtk_object_set_data_full (GTK_OBJECT (gum), "INL_NOTEBOOK_LABEL", INL_NOTEBOOK_LABEL, (GtkDestroyNotify) gtk_widget_unref); gtk_widget_show (INL_NOTEBOOK_LABEL); - gtk_notebook_set_tab_label (GTK_NOTEBOOK (notebook1), gtk_notebook_get_nth_page (GTK_NOTEBOOK (notebook1), 10), INL_NOTEBOOK_LABEL); + gtk_notebook_set_tab_label (GTK_NOTEBOOK (notebook1), gtk_notebook_get_nth_page (GTK_NOTEBOOK (notebook1), 8), INL_NOTEBOOK_LABEL); + + table7 = gtk_table_new (4, 2, FALSE); + gtk_widget_ref (table7); + gtk_object_set_data_full (GTK_OBJECT (gum), "table7", table7, + (GtkDestroyNotify) gtk_widget_unref); + gtk_widget_show (table7); + gtk_container_add (GTK_CONTAINER (notebook1), table7); + gtk_container_set_border_width (GTK_CONTAINER (table7), 6); + gtk_table_set_row_spacings (GTK_TABLE (table7), 6); + gtk_table_set_col_spacings (GTK_TABLE (table7), 6); + + label126 = gtk_label_new ("Base Practice Mode Settings\n"); + gtk_widget_ref (label126); + gtk_object_set_data_full (GTK_OBJECT (gum), "label126", label126, + (GtkDestroyNotify) gtk_widget_unref); + gtk_widget_show (label126); + gtk_table_attach (GTK_TABLE (table7), label126, 0, 2, 0, 1, + (GtkAttachOptions) (GTK_EXPAND | GTK_FILL), + (GtkAttachOptions) (GTK_FILL), 0, 0); + + BASEPRACTICE_LABEL = gtk_label_new ("BASEPRACTICE:"); + gtk_widget_ref (BASEPRACTICE_LABEL); + gtk_object_set_data_full (GTK_OBJECT (gum), "BASEPRACTICE_LABEL", BASEPRACTICE_LABEL, + (GtkDestroyNotify) gtk_widget_unref); + gtk_widget_show (BASEPRACTICE_LABEL); + gtk_table_attach (GTK_TABLE (table7), BASEPRACTICE_LABEL, 0, 1, 1, 2, + (GtkAttachOptions) (GTK_FILL), + (GtkAttachOptions) (GTK_FILL), 0, 0); + gtk_misc_set_alignment (GTK_MISC (BASEPRACTICE_LABEL), 1, 0.5); + gtk_misc_set_padding (GTK_MISC (BASEPRACTICE_LABEL), 10, 0); + + ROBOTHOST_LABEL = gtk_label_new ("ROBOTHOST:"); + gtk_widget_ref (ROBOTHOST_LABEL); + gtk_object_set_data_full (GTK_OBJECT (gum), "ROBOTHOST_LABEL", ROBOTHOST_LABEL, + (GtkDestroyNotify) gtk_widget_unref); + gtk_widget_show (ROBOTHOST_LABEL); + gtk_table_attach (GTK_TABLE (table7), ROBOTHOST_LABEL, 0, 1, 2, 3, + (GtkAttachOptions) (GTK_FILL), + (GtkAttachOptions) (GTK_FILL), 0, 0); + gtk_misc_set_alignment (GTK_MISC (ROBOTHOST_LABEL), 1, 0.5); + gtk_misc_set_padding (GTK_MISC (ROBOTHOST_LABEL), 10, 0); + + hbox42 = gtk_hbox_new (FALSE, 0); + gtk_widget_ref (hbox42); + gtk_object_set_data_full (GTK_OBJECT (gum), "hbox42", hbox42, + (GtkDestroyNotify) gtk_widget_unref); + gtk_widget_show (hbox42); + gtk_table_attach (GTK_TABLE (table7), hbox42, 1, 2, 1, 2, + (GtkAttachOptions) (GTK_FILL), + (GtkAttachOptions) (GTK_FILL), 0, 0); + + BASEPRACTICE_0 = gtk_radio_button_new_with_label (BASEPRACTICE_group, "No"); + BASEPRACTICE_group = gtk_radio_button_group (GTK_RADIO_BUTTON (BASEPRACTICE_0)); + gtk_widget_ref (BASEPRACTICE_0); + gtk_object_set_data_full (GTK_OBJECT (gum), "BASEPRACTICE_0", BASEPRACTICE_0, + (GtkDestroyNotify) gtk_widget_unref); + gtk_widget_show (BASEPRACTICE_0); + gtk_box_pack_start (GTK_BOX (hbox42), BASEPRACTICE_0, FALSE, FALSE, 0); + + BASEPRACTICE_1 = gtk_radio_button_new_with_label (BASEPRACTICE_group, "Yes"); + BASEPRACTICE_group = gtk_radio_button_group (GTK_RADIO_BUTTON (BASEPRACTICE_1)); + gtk_widget_ref (BASEPRACTICE_1); + gtk_object_set_data_full (GTK_OBJECT (gum), "BASEPRACTICE_1", BASEPRACTICE_1, + (GtkDestroyNotify) gtk_widget_unref); + gtk_widget_show (BASEPRACTICE_1); + gtk_box_pack_start (GTK_BOX (hbox42), BASEPRACTICE_1, FALSE, FALSE, 0); + + hbox43 = gtk_hbox_new (FALSE, 0); + gtk_widget_ref (hbox43); + gtk_object_set_data_full (GTK_OBJECT (gum), "hbox43", hbox43, + (GtkDestroyNotify) gtk_widget_unref); + gtk_widget_show (hbox43); + gtk_table_attach (GTK_TABLE (table7), hbox43, 1, 2, 2, 3, + (GtkAttachOptions) (GTK_FILL), + (GtkAttachOptions) (GTK_FILL), 0, 0); + + ROBOTHOST = gtk_entry_new (); + gtk_widget_ref (ROBOTHOST); + gtk_object_set_data_full (GTK_OBJECT (gum), "ROBOTHOST", ROBOTHOST, + (GtkDestroyNotify) gtk_widget_unref); + gtk_widget_show (ROBOTHOST); + gtk_box_pack_start (GTK_BOX (hbox43), ROBOTHOST, TRUE, TRUE, 0); + + label127 = gtk_label_new (""); + gtk_widget_ref (label127); + gtk_object_set_data_full (GTK_OBJECT (gum), "label127", label127, + (GtkDestroyNotify) gtk_widget_unref); + gtk_widget_show (label127); + gtk_table_attach (GTK_TABLE (table7), label127, 0, 2, 3, 4, + (GtkAttachOptions) (GTK_FILL), + (GtkAttachOptions) (GTK_EXPAND | GTK_FILL), 0, 0); + + label51 = gtk_label_new ("Base Practice"); + gtk_widget_ref (label51); + gtk_object_set_data_full (GTK_OBJECT (gum), "label51", label51, + (GtkDestroyNotify) gtk_widget_unref); + gtk_widget_show (label51); + gtk_notebook_set_tab_label (GTK_NOTEBOOK (notebook1), gtk_notebook_get_nth_page (GTK_NOTEBOOK (notebook1), 9), label51); + + table8 = gtk_table_new (3, 2, FALSE); + gtk_widget_ref (table8); + gtk_object_set_data_full (GTK_OBJECT (gum), "table8", table8, + (GtkDestroyNotify) gtk_widget_unref); + gtk_widget_show (table8); + gtk_container_add (GTK_CONTAINER (notebook1), table8); + gtk_container_set_border_width (GTK_CONTAINER (table8), 6); + gtk_table_set_row_spacings (GTK_TABLE (table8), 6); + gtk_table_set_col_spacings (GTK_TABLE (table8), 6); + + label128 = gtk_label_new ("Hockey Mode Settings\n"); + gtk_widget_ref (label128); + gtk_object_set_data_full (GTK_OBJECT (gum), "label128", label128, + (GtkDestroyNotify) gtk_widget_unref); + gtk_widget_show (label128); + gtk_table_attach (GTK_TABLE (table8), label128, 0, 2, 0, 1, + (GtkAttachOptions) (GTK_EXPAND | GTK_FILL), + (GtkAttachOptions) (GTK_FILL), 0, 0); + + HOCKEY_LABEL = gtk_label_new ("HOCKEY:"); + gtk_widget_ref (HOCKEY_LABEL); + gtk_object_set_data_full (GTK_OBJECT (gum), "HOCKEY_LABEL", HOCKEY_LABEL, + (GtkDestroyNotify) gtk_widget_unref); + gtk_widget_show (HOCKEY_LABEL); + gtk_table_attach (GTK_TABLE (table8), HOCKEY_LABEL, 0, 1, 1, 2, + (GtkAttachOptions) (GTK_FILL), + (GtkAttachOptions) (GTK_FILL), 0, 0); + gtk_misc_set_alignment (GTK_MISC (HOCKEY_LABEL), 1, 0.5); + gtk_misc_set_padding (GTK_MISC (HOCKEY_LABEL), 10, 0); + + hbox44 = gtk_hbox_new (FALSE, 0); + gtk_widget_ref (hbox44); + gtk_object_set_data_full (GTK_OBJECT (gum), "hbox44", hbox44, + (GtkDestroyNotify) gtk_widget_unref); + gtk_widget_show (hbox44); + gtk_table_attach (GTK_TABLE (table8), hbox44, 1, 2, 1, 2, + (GtkAttachOptions) (GTK_FILL), + (GtkAttachOptions) (GTK_FILL), 0, 0); + + HOCKEY_0 = gtk_radio_button_new_with_label (HOCKEY_group, "No"); + HOCKEY_group = gtk_radio_button_group (GTK_RADIO_BUTTON (HOCKEY_0)); + gtk_widget_ref (HOCKEY_0); + gtk_object_set_data_full (GTK_OBJECT (gum), "HOCKEY_0", HOCKEY_0, + (GtkDestroyNotify) gtk_widget_unref); + gtk_widget_show (HOCKEY_0); + gtk_box_pack_start (GTK_BOX (hbox44), HOCKEY_0, FALSE, FALSE, 0); + + HOCKEY_1 = gtk_radio_button_new_with_label (HOCKEY_group, "Yes"); + HOCKEY_group = gtk_radio_button_group (GTK_RADIO_BUTTON (HOCKEY_1)); + gtk_widget_ref (HOCKEY_1); + gtk_object_set_data_full (GTK_OBJECT (gum), "HOCKEY_1", HOCKEY_1, + (GtkDestroyNotify) gtk_widget_unref); + gtk_widget_show (HOCKEY_1); + gtk_box_pack_start (GTK_BOX (hbox44), HOCKEY_1, FALSE, FALSE, 0); + + label131 = gtk_label_new (""); + gtk_widget_ref (label131); + gtk_object_set_data_full (GTK_OBJECT (gum), "label131", label131, + (GtkDestroyNotify) gtk_widget_unref); + gtk_widget_show (label131); + gtk_table_attach (GTK_TABLE (table8), label131, 0, 2, 2, 3, + (GtkAttachOptions) (GTK_EXPAND | GTK_FILL), + (GtkAttachOptions) (GTK_EXPAND | GTK_FILL), 0, 0); + + label54 = gtk_label_new ("Hockey"); + gtk_widget_ref (label54); + gtk_object_set_data_full (GTK_OBJECT (gum), "label54", label54, + (GtkDestroyNotify) gtk_widget_unref); + gtk_widget_show (label54); + gtk_notebook_set_tab_label (GTK_NOTEBOOK (notebook1), gtk_notebook_get_nth_page (GTK_NOTEBOOK (notebook1), 10), label54); table10 = gtk_table_new (6, 2, FALSE); gtk_widget_ref (table10); @@ -4157,15 +4208,15 @@ NULL); gtk_widget_add_accelerator (PING_FREQ, "grab_focus", accel_group, - PING_FREQ_LABEL_key, GDK_MOD1_MASK, 0); + PING_FREQ_LABEL_key, GDK_MOD1_MASK, (GtkAccelFlags) 0); gtk_widget_add_accelerator (PING_ILOSS_INTERVAL, "grab_focus", accel_group, - PING_ILOSS_INTERVAL_LABEL_key, GDK_MOD1_MASK, 0); + PING_ILOSS_INTERVAL_LABEL_key, GDK_MOD1_MASK, (GtkAccelFlags) 0); gtk_widget_add_accelerator (PING_GHOSTBUST, "grab_focus", accel_group, - PING_GHOSTBUST_LABEL_key, GDK_MOD1_MASK, 0); + PING_GHOSTBUST_LABEL_key, GDK_MOD1_MASK, (GtkAccelFlags) 0); gtk_widget_add_accelerator (PING_GHOSTBUST_INTERVAL, "grab_focus", accel_group, - PING_GHOSTBUST_INTERVAL_LABEL_key, GDK_MOD1_MASK, 0); + PING_GHOSTBUST_INTERVAL_LABEL_key, GDK_MOD1_MASK, (GtkAccelFlags) 0); gtk_widget_add_accelerator (SAVE_DOG_STAT, "grab_focus", accel_group, - SAVE_DOG_STAT_LABEL_key, GDK_MOD1_MASK, 0); + SAVE_DOG_STAT_LABEL_key, GDK_MOD1_MASK, (GtkAccelFlags) 0); gtk_object_set_data (GTK_OBJECT (gum), "tooltips", tooltips); Index: Vanilla/gum/support.c diff -u Vanilla/gum/support.c:1.3 Vanilla/gum/support.c:1.4 --- Vanilla/gum/support.c:1.3 Tue Apr 17 23:41:35 2001 +++ Vanilla/gum/support.c Fri Feb 13 23:28:14 2004 @@ -97,6 +97,9 @@ GtkWidget *pixmap; GList *elem; + if (!filename || !filename[0]) + return create_dummy_pixmap (widget); + /* We first try any pixmaps directories set by the application. */ elem = pixmaps_directories; while (elem) @@ -136,7 +139,7 @@ } /* This is an internally used function to check if a pixmap file exists. */ -gchar* +static gchar* check_file_exists (const gchar *directory, const gchar *filename) { _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From vanilla-devel at us.netrek.org Sun Feb 15 19:45:47 2004 From: vanilla-devel at us.netrek.org (Vanilla CVS Development) Date: Wed Jan 12 00:50:54 2005 Subject: [Vanilla Devel] CVS update: Vanilla/include Message-ID: <200402160145.i1G1jlX06156@swashbuckler.real-time.com> Date: Sunday February 15, 2004 @ 19:45 Author: cameron Update of /home/netrek/cvsroot/Vanilla/include In directory swashbuckler.real-time.com:/var/tmp/cvs-serv6142/include Modified Files: config.h.in data.h defs.h patchlevel.h sysdefaults.h Log Message: add player file index support **************************************** Index: Vanilla/include/config.h.in diff -u Vanilla/include/config.h.in:1.4 Vanilla/include/config.h.in:1.5 --- Vanilla/include/config.h.in:1.4 Mon Jul 7 17:19:55 2003 +++ Vanilla/include/config.h.in Sun Feb 15 19:45:46 2004 @@ -459,6 +459,16 @@ active. */ #undef NO_BEAM_DOWN_OUT_OF_T_MODE + /* PLAYER_INDEX - create and maintain + an index of the player database, to + reduce time to log in for servers with + large or untrimmed player databases, + requires libgdbm, and indexes only + characters who return to the + server. */ +#define PLAYER_INDEX + + #endif /* SERVER */ Index: Vanilla/include/data.h diff -u Vanilla/include/data.h:1.3 Vanilla/include/data.h:1.4 --- Vanilla/include/data.h:1.3 Mon Jul 7 17:19:55 2003 +++ Vanilla/include/data.h Sun Feb 15 19:45:47 2004 @@ -1,4 +1,4 @@ -/* $Id: data.h,v 1.3 2003/07/07 22:19:55 ahn Exp $ +/* $Id: data.h,v 1.4 2004/02/16 01:45:47 cameron Exp $ */ #ifndef _h_data @@ -258,6 +258,7 @@ extern char Robot[FNAMESIZE]; extern char LogFileName[FNAMESIZE]; extern char PlayerFile[FNAMESIZE]; +extern char PlayerIndexFile[FNAMESIZE]; extern char ConqFile[FNAMESIZE]; extern char SysDef_File[FNAMESIZE]; extern char Time_File[FNAMESIZE]; Index: Vanilla/include/defs.h diff -u Vanilla/include/defs.h:1.3 Vanilla/include/defs.h:1.4 --- Vanilla/include/defs.h:1.3 Wed Jan 7 20:42:20 2004 +++ Vanilla/include/defs.h Sun Feb 15 19:45:47 2004 @@ -1,4 +1,4 @@ -/* $Id: defs.h,v 1.3 2004/01/08 02:42:20 unbelver Exp $ +/* $Id: defs.h,v 1.4 2004/02/16 01:45:47 cameron Exp $ */ #ifndef _h_defs @@ -207,6 +207,7 @@ #define N_ROBOT "robotII" #define N_LOGFILENAME "logfile" #define N_PLAYERFILE ".players" +#define N_PLAYERINDEXFILE ".players.index" #define N_CONQFILE ".conquer" #define N_SYSDEF_FILE ".sysdef" #define N_TIME_FILE ".time" Index: Vanilla/include/patchlevel.h diff -u Vanilla/include/patchlevel.h:1.1 Vanilla/include/patchlevel.h:1.2 --- Vanilla/include/patchlevel.h:1.1 Tue May 1 21:00:19 2001 +++ Vanilla/include/patchlevel.h Sun Feb 15 19:45:47 2004 @@ -12,7 +12,7 @@ * (a) reset this to zero before each major release, and; * (b) increment this number before each patch release. */ -#define PATCHLEVEL 8 +#define PATCHLEVEL 9 #if !defined(NULL) #define NULL 0 #endif Index: Vanilla/include/sysdefaults.h diff -u Vanilla/include/sysdefaults.h:1.3 Vanilla/include/sysdefaults.h:1.4 --- Vanilla/include/sysdefaults.h:1.3 Mon Jul 7 17:19:55 2003 +++ Vanilla/include/sysdefaults.h Sun Feb 15 19:45:47 2004 @@ -1,4 +1,4 @@ -/* $Id: sysdefaults.h,v 1.3 2003/07/07 22:19:55 ahn Exp $ */ +/* $Id: sysdefaults.h,v 1.4 2004/02/16 01:45:47 cameron Exp $ */ /* structure for default values that are represented as array of flags */ struct sysdef_array { @@ -202,11 +202,11 @@ /* Procedure for adding new default value. -James Cameron, 28th February 2000. +James Cameron, 14th February 2004. - add to ntserv/data.c -- add to ntserv/data.h -- add to sysdef_keywords in ntserv/sysdefaults.h, in any order, prefer end +- add to include/data.h +- add to sysdef_keywords in include/sysdefaults.h, in any order, prefer end - add to docs/sample_sysdef with comment about value meanings - use glade (http://glade.pn.org/) to add to gum/gum.xml and regenerate code - leave a comment here if your defaults have not been added to gum _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From vanilla-devel at us.netrek.org Sun Feb 15 19:45:46 2004 From: vanilla-devel at us.netrek.org (Vanilla CVS Development) Date: Wed Jan 12 00:50:54 2005 Subject: [Vanilla Devel] CVS update: Vanilla/docs Message-ID: <200402160145.i1G1jkq06151@swashbuckler.real-time.com> Date: Sunday February 15, 2004 @ 19:45 Author: cameron Update of /home/netrek/cvsroot/Vanilla/docs In directory swashbuckler.real-time.com:/var/tmp/cvs-serv6142/docs Modified Files: players-file-redesign.txt Log Message: add player file index support **************************************** Index: Vanilla/docs/players-file-redesign.txt diff -u Vanilla/docs/players-file-redesign.txt:1.1 Vanilla/docs/players-file-redesign.txt:1.2 --- Vanilla/docs/players-file-redesign.txt:1.1 Wed May 29 20:31:26 2002 +++ Vanilla/docs/players-file-redesign.txt Sun Feb 15 19:45:46 2004 @@ -160,3 +160,15 @@ - else if found, append .index record, return offset - cause tools that write new .players file to remove .index file +second design idea, 2004-02 + +- use libgdbm3 GNU dbm database + - player name as key + - .players offset as value +- getname.c + - find entry in dbm + - if not found, + - do manual search + - if found, lock, add to dbm, unlock + - else if found, use normally. +- cause tools that write new .players file to remove .index file _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From vanilla-devel at us.netrek.org Sun Feb 15 19:45:47 2004 From: vanilla-devel at us.netrek.org (Vanilla CVS Development) Date: Wed Jan 12 00:50:54 2005 Subject: [Vanilla Devel] CVS update: Vanilla/ntserv Message-ID: <200402160145.i1G1jlk06165@swashbuckler.real-time.com> Date: Sunday February 15, 2004 @ 19:45 Author: cameron Update of /home/netrek/cvsroot/Vanilla/ntserv In directory swashbuckler.real-time.com:/var/tmp/cvs-serv6142/ntserv Modified Files: Makefile.in data.c db.c getname.c getpath.c Log Message: add player file index support **************************************** Index: Vanilla/ntserv/Makefile.in diff -u Vanilla/ntserv/Makefile.in:1.5 Vanilla/ntserv/Makefile.in:1.6 --- Vanilla/ntserv/Makefile.in:1.5 Wed Sep 24 04:20:19 2003 +++ Vanilla/ntserv/Makefile.in Sun Feb 15 19:45:47 2004 @@ -73,6 +73,9 @@ commands.o: $(PMAKE) ${srcdir}/commands.c $(CC) $(CFLAGS) $(DEP) -c ${srcdir}/commands.c +db.o: ($PMAKE) db.c + $(CC) $(CFLAGS) $(DEP) `glib-config --cflags` -c $db.c + cflags: echo "static char cflags[]=\"$(CFLAGS) $(LIBS)\";" >../cflags.h Index: Vanilla/ntserv/data.c diff -u Vanilla/ntserv/data.c:1.19 Vanilla/ntserv/data.c:1.20 --- Vanilla/ntserv/data.c:1.19 Mon Jul 7 17:19:55 2003 +++ Vanilla/ntserv/data.c Sun Feb 15 19:45:47 2004 @@ -1,4 +1,4 @@ -/* $Id: data.c,v 1.19 2003/07/07 22:19:55 ahn Exp $ +/* $Id: data.c,v 1.20 2004/02/16 01:45:47 cameron Exp $ */ #include "copyright.h" @@ -237,6 +237,7 @@ char Robot[FNAMESIZE]; char LogFileName[FNAMESIZE]; char PlayerFile[FNAMESIZE]; +char PlayerIndexFile[FNAMESIZE]; char ConqFile[FNAMESIZE]; char SysDef_File[FNAMESIZE]; char Time_File[FNAMESIZE]; Index: Vanilla/ntserv/db.c diff -u Vanilla/ntserv/db.c:1.1 Vanilla/ntserv/db.c:1.2 --- Vanilla/ntserv/db.c:1.1 Wed Sep 24 04:14:02 2003 +++ Vanilla/ntserv/db.c Sun Feb 15 19:45:47 2004 @@ -11,7 +11,11 @@ #include #include #include +#include #include +#ifdef PLAYER_INDEX +#include +#endif #include "defs.h" #include INC_STRINGS #include INC_UNISTD @@ -19,35 +23,169 @@ #include "data.h" #include "salt.h" +/* support for timing requires glib, not expected to remain */ +#define DB_TIMING 1 +#ifdef DB_TIMING +#include +#endif + +#ifdef PLAYER_INDEX + +/* fetch the offset to a player from the index database */ +static off_t db_index_fetch(char *namePick, struct statentry *player) { + GDBM_FILE dbf; + datum key, content; + off_t position; + + /* open the player index database */ + dbf = gdbm_open(PlayerIndexFile, 0, GDBM_WRCREAT, 0644, NULL); + if (dbf == NULL) { + ERROR(1,("db.c: db_index_fetch: gdbm_open('%s'): '%s', '%s'\n", + PlayerIndexFile, gdbm_strerror(gdbm_errno), strerror(errno))); + return -1; + } + ERROR(8,("db.c: db_index_fetch: gdbm_open('%s'): ok\n", + PlayerIndexFile)); + + /* fetch the database entry for this player name */ + key.dptr = namePick; + key.dsize = strlen(namePick); + content = gdbm_fetch(dbf, key); + + /* player index may not contain this player, that's fine */ + if (content.dptr == NULL) { + ERROR(8,("db.c: db_index_fetch: gdbm_fetch('%s'): not found in index\n", + namePick)); + gdbm_close(dbf); + return -1; + } + + if (content.dsize != sizeof(off_t)) { + ERROR(8,("db.c: db_index_fetch: gdbm_fetch('%s'): dsize [%d] not sizeof(off_t) [%d]\n", + namePick, content.dsize, sizeof(off_t))); + gdbm_close(dbf); + return -1; + } + + /* return the position from the database entry */ + position = *((off_t *) content.dptr); + free(content.dptr); + gdbm_close(dbf); + ERROR(8,("db.c: db_index_fetch: gdbm_fetch('%s'): index says position '%d'\n", + namePick, position)); + return position; +} + +/* store the offset to a player into the index database */ +static void db_index_store(struct statentry *player, off_t position) { + GDBM_FILE dbf; + datum key, content; + + /* open the player index database */ + dbf = gdbm_open(PlayerIndexFile, 0, GDBM_WRCREAT, 0644, NULL); + if (dbf == NULL) { return; } + + /* prepare the key and content pair from name and position */ + key.dptr = player->name; + key.dsize = strlen(player->name); + content.dptr = (char *) &position; + content.dsize = sizeof(position); + + /* store this key and position */ + if (gdbm_store(dbf, key, content, GDBM_REPLACE) < 0) { + ERROR(8,("db.c: db_index_store: gdbm_store('%s' -> '%d'): %s, %s\n", + player->name, position, gdbm_strerror(gdbm_errno), + strerror(errno))); + gdbm_close(dbf); + return; + } + + ERROR(8,("db.c: db_index_store: gdbm_store('%s' -> '%d'): ok\n", + player->name, position)); + gdbm_close(dbf); +} +#endif /* given a name, find the player in the file, return position */ int findplayer(char *namePick, struct statentry *player) { - int position, plfd; + off_t position; + int fd; +#ifdef DB_TIMING + GTimer *timer = g_timer_new(); +#endif - /* open the player file to find the player */ - plfd = open(PlayerFile, O_RDONLY, 0644); - if (plfd < 0) { - ERROR(1,("I cannot open the player file!\n")); - ERROR(1,("Error number: %d\n", errno)); + /* open the player file */ + fd = open(PlayerFile, O_RDONLY, 0644); + if (fd < 0) { + ERROR(1,("db.c: findplayer: open('%s'): '%s'\n", PlayerFile, + strerror(errno))); strcpy(player->name, namePick); +#ifdef DB_TIMING + g_timer_destroy(timer); +#endif return -1; } +#ifdef PLAYER_INDEX + /* use the index as a hint as to position in the player file */ + position = db_index_fetch(namePick, player); + + /* if an index entry was present, read the entry to check it's right */ + if (position != -1) { + lseek(fd, position * sizeof(struct statentry), SEEK_SET); + if (read(fd, (char *) player, sizeof(struct statentry)) < 0) { + /* read failed for some reason */ + ERROR(1,("db.c: findplayer: read: '%s'\n", strerror(errno))); + strcpy(player->name, ""); + } + /* check the entry in the main file matches what the index said */ + if (strcmp(namePick, player->name)==0) { + close(fd); + ERROR(8,("db.c: findplayer: ok, '%s' is indeed at position '%d'\n", + namePick, position)); +#ifdef DB_TIMING + ERROR(8,("db.c: timing, cached resolution, %f\n", g_timer_elapsed(timer, NULL))); + g_timer_destroy(timer); +#endif + return position; + } + /* otherwise there's an inconsistency that we can recover from */ + ERROR(2,("db.c: findplayer: player index inconsistent with player file, entered name '%s', index says position '%d', but file entry name '%s'\n", namePick, position, player->name)); + /* return file to start for sequential search */ + lseek(fd, 0, SEEK_SET); + } +#endif + /* sequential search of player file */ position = 0; - while (read(plfd, (char *) player, sizeof(struct statentry)) == + while (read(fd, (char *) player, sizeof(struct statentry)) == sizeof(struct statentry)) { if (strcmp(namePick, player->name)==0) { - close(plfd); + close(fd); +#ifdef PLAYER_INDEX + db_index_store(player, position); +#endif + ERROR(8,("db.c: findplayer: '%s' found in sequential scan at position '%d'\n", + namePick, position)); +#ifdef DB_TIMING + ERROR(8,("db.c: timing, sequential resolution, %f\n", g_timer_elapsed(timer, NULL))); + g_timer_destroy(timer); +#endif return position; } position++; } /* not found, return failure */ - close(plfd); + close(fd); strcpy(player->name, namePick); + ERROR(8,("db.c: findplayer: '%s' not found in sequential scan\n", + namePick)); +#ifdef DB_TIMING + ERROR(8,("db.c: timing, sequential failure, %f\n", g_timer_elapsed(timer, NULL))); + g_timer_destroy(timer); +#endif return -1; } @@ -55,6 +193,7 @@ { int fd; if (me->p_pos < 0) return; + ERROR(8,("db.c: savepass: saving to position '%d'\n", me->p_pos)); fd = open(PlayerFile, O_WRONLY, 0644); if (fd >= 0) { lseek(fd, me->p_pos * sizeof(struct statentry) + @@ -95,12 +234,24 @@ int newplayer(struct statentry *player) { - int plfd, file_pos; + int fd, offset, position; + + ERROR(8,("db.c: newplayer: adding '%s'\n", player->name)); + + fd = open(PlayerFile, O_RDWR|O_CREAT, 0644); + if (fd < 0) return -1; + if ((offset = lseek(fd, 0, SEEK_END)) < 0) return -1; + write(fd, (char *) player, sizeof(struct statentry)); + close(fd); + position = offset / sizeof(struct statentry); + + ERROR(8,("db.c: newplayer: sizeof '%d' offset '%d' position '%d'\n", + sizeof(struct statentry), offset, position)); + +#ifdef PLAYER_INDEX + /* do not create an index entry until the character name is reused, + because not all characters are re-used */ +#endif - plfd = open(PlayerFile, O_RDWR|O_CREAT, 0644); - if (plfd < 0) return -1; - if ((file_pos = lseek(plfd, 0, SEEK_END)) < 0) return -1; - write(plfd, (char *) &player, sizeof(struct statentry)); - close(plfd); - return file_pos / sizeof(struct statentry); + return position; } Index: Vanilla/ntserv/getname.c diff -u Vanilla/ntserv/getname.c:1.13 Vanilla/ntserv/getname.c:1.14 --- Vanilla/ntserv/getname.c:1.13 Sat Aug 23 01:14:19 2003 +++ Vanilla/ntserv/getname.c Sun Feb 15 19:45:47 2004 @@ -68,12 +68,10 @@ readFromClient(); } - /* ERROR(8,("handleLogin: %s %s %s\n", passPick[15] == 0 ? "attempt" : "query", namePick, passPick)); - */ - if ((strcmp(namePick, "Guest")==0 || strcmp(namePick, "guest")==0) && + if (streq(namePick, "Guest") || streq(namePick, "guest") && !lockout()) { handlelogin_guest: @@ -83,7 +81,7 @@ flushSockBuf(); return; } - /* todo: we don't check for existing players on INL robot entry */ + /* todo: we don't check for existing guests on INL robot entry */ hourratio=5; MZERO(&player.stats, sizeof(struct stats)); @@ -132,13 +130,13 @@ hourratio=1; /* We look for the guy in the stat file */ - if (strcmp(player.name, namePick) != 0) { + if (!streq(player.name, namePick)) { position = findplayer(namePick, &player); } /* Was this just a query? */ if (passPick[15]!=0) { - if (position== -1) { + if (position == -1) { sendClientLogin(NULL); } else { sendClientLogin(&player.stats); @@ -164,7 +162,7 @@ #endif /* A new guy? */ - if ((position== -1) && !lockout()) { + if ((position == -1) && !lockout()) { strcpy(player.name, namePick); /* Linux: compiler warnings with -Wall here, as crypt is in unistd.h but needs _XOPEN_SOURCE defined, which then breaks lots of other @@ -202,10 +200,10 @@ !streq(player.password, (char *) crypt(passPick, player.password)))) { sendClientLogin(NULL); flushSockBuf(); - /* ERROR(8,("handleLogin: password-failure namePick=%s passPick=%s file=%s newstyle=%s oldstyle=%s\n", namePick, passPick, player.password, newpass, (char *) crypt(passPick, player.password))); */ + ERROR(8,("handleLogin: password-failure namePick=%s passPick=%s file=%s newstyle=%s oldstyle=%s\n", namePick, passPick, player.password, newpass, (char *) crypt(passPick, player.password))); return; } - /* ERROR(8,("handleLogin: password-success namePick=%s passPick=%s file=%s newstyle=%s oldstyle=%s\n", namePick, passPick, player.password, newpass, (char *) crypt(passPick, player.password))); */ + ERROR(8,("handleLogin: password-success namePick=%s passPick=%s file=%s newstyle=%s oldstyle=%s\n", namePick, passPick, player.password, newpass, (char *) crypt(passPick, player.password))); sendClientLogin(&player.stats); strcpy(me->p_name, namePick); me->p_pos=position; Index: Vanilla/ntserv/getpath.c diff -u Vanilla/ntserv/getpath.c:1.6 Vanilla/ntserv/getpath.c:1.7 --- Vanilla/ntserv/getpath.c:1.6 Mon Jul 7 17:19:55 2003 +++ Vanilla/ntserv/getpath.c Sun Feb 15 19:45:47 2004 @@ -41,6 +41,8 @@ sprintf(PlayerFile,"%s/%s",path,N_PLAYERFILE); + sprintf(PlayerIndexFile,"%s/%s",path,N_PLAYERINDEXFILE); + sprintf(ConqFile,"%s/%s",path,N_CONQFILE); sprintf(SysDef_File,"%s/%s",path,N_SYSDEF_FILE); _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From vanilla-devel at us.netrek.org Sun Feb 15 19:45:46 2004 From: vanilla-devel at us.netrek.org (Vanilla CVS Development) Date: Wed Jan 12 00:50:54 2005 Subject: [Vanilla Devel] CVS update: Vanilla Message-ID: <200402160145.i1G1jkD06145@swashbuckler.real-time.com> Date: Sunday February 15, 2004 @ 19:45 Author: cameron Update of /home/netrek/cvsroot/Vanilla In directory swashbuckler.real-time.com:/var/tmp/cvs-serv6142 Modified Files: ChangeLog README.releasing Log Message: add player file index support **************************************** Index: Vanilla/ChangeLog diff -u Vanilla/ChangeLog:1.147 Vanilla/ChangeLog:1.148 --- Vanilla/ChangeLog:1.147 Fri Feb 13 22:03:37 2004 +++ Vanilla/ChangeLog Sun Feb 15 19:45:46 2004 @@ -1,3 +1,16 @@ +Sun Feb 15 22:47:15 2004 James Cameron + + * ntserv/db.c, ntserv/Makefile.in, ntserv/Makefile: add database + access timing, temporary support for glib linked with ntserv and + for compile of db.c, a more comprehensive solution would involve + conditionals determined at configure time. + + * include/config.h.in: add PLAYER_INDEX define, default on, + requires libgdbm, ==TODO== add to configure. + * ntserv/db.c: add creation and maintenance of the player index. + * include/defs.h, ntserv/data.c, include/data.h, ntserv/getpath.c + (getpath): add player index file name. + Sat Feb 14 14:59:37 2004 James Cameron * robotd/Makefile.in (install): place robot where pret and other @@ -1503,4 +1516,4 @@ update_sys_defaults in updateMessages to a more appropriate location - updateClient in socket.c. - $Id: ChangeLog,v 1.147 2004/02/14 04:03:37 cameron Exp $ + $Id: ChangeLog,v 1.148 2004/02/16 01:45:46 cameron Exp $ Index: Vanilla/README.releasing diff -u Vanilla/README.releasing:1.8 Vanilla/README.releasing:1.9 --- Vanilla/README.releasing:1.8 Sat Aug 23 01:14:18 2003 +++ Vanilla/README.releasing Sun Feb 15 19:45:46 2004 @@ -1,5 +1,5 @@ -$Id: README.releasing,v 1.8 2003/08/23 06:14:18 cameron Exp $ +$Id: README.releasing,v 1.9 2004/02/16 01:45:46 cameron Exp $ Release Procedure @@ -8,8 +8,8 @@ cd Vanilla # set variables to ease the rest of this ... (sh or bash) -VS=2.9pl8 -VL=v_2_9_8 +VS=2.9pl9 +VL=v_2_9_9 # make sure you have committed all changes cvs -z9 diff -u > tmp.tmp _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From quozl at us.netrek.org Sun Feb 15 23:56:01 2004 From: quozl at us.netrek.org (James Cameron) Date: Wed Jan 12 00:50:54 2005 Subject: [Vanilla Devel] Re: Player database problems In-Reply-To: <20040205214949.GA27495@us.netrek.org> References: <5.2.0.9.0.20040205161749.01cad230@mailgate.team17.com> <20040205214949.GA27495@us.netrek.org> Message-ID: <20040216055601.GB24067@us.netrek.org> The player database problems were definitely my fault. The changes had found their way into CVS without testing. I've reworked this, and finished off the player file index as well, and committed it to CVS after some standalone server testing. -- James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/ _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From vanilla-devel at us.netrek.org Mon Feb 16 00:10:16 2004 From: vanilla-devel at us.netrek.org (Vanilla CVS Development) Date: Wed Jan 12 00:50:54 2005 Subject: [Vanilla Devel] CVS update: Vanilla/ntserv Message-ID: <200402160610.i1G6AGl06248@swashbuckler.real-time.com> Date: Monday February 16, 2004 @ 0:10 Author: cameron Update of /home/netrek/cvsroot/Vanilla/ntserv In directory swashbuckler.real-time.com:/var/tmp/cvs-serv6245 Modified Files: Makefile.in Log Message: oops **************************************** Index: Vanilla/ntserv/Makefile.in diff -u Vanilla/ntserv/Makefile.in:1.6 Vanilla/ntserv/Makefile.in:1.7 --- Vanilla/ntserv/Makefile.in:1.6 Sun Feb 15 19:45:47 2004 +++ Vanilla/ntserv/Makefile.in Mon Feb 16 00:10:16 2004 @@ -73,7 +73,7 @@ commands.o: $(PMAKE) ${srcdir}/commands.c $(CC) $(CFLAGS) $(DEP) -c ${srcdir}/commands.c -db.o: ($PMAKE) db.c +db.o: $(PMAKE) db.c $(CC) $(CFLAGS) $(DEP) `glib-config --cflags` -c $db.c cflags: _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From vanilla-devel at us.netrek.org Mon Feb 16 00:14:56 2004 From: vanilla-devel at us.netrek.org (Vanilla CVS Development) Date: Wed Jan 12 00:50:54 2005 Subject: [Vanilla Devel] CVS update: Vanilla/ntserv Message-ID: <200402160614.i1G6EuM06256@swashbuckler.real-time.com> Date: Monday February 16, 2004 @ 0:14 Author: cameron Update of /home/netrek/cvsroot/Vanilla/ntserv In directory swashbuckler.real-time.com:/var/tmp/cvs-serv6253 Modified Files: Makefile.in Log Message: oops 2 **************************************** Index: Vanilla/ntserv/Makefile.in diff -u Vanilla/ntserv/Makefile.in:1.7 Vanilla/ntserv/Makefile.in:1.8 --- Vanilla/ntserv/Makefile.in:1.7 Mon Feb 16 00:10:16 2004 +++ Vanilla/ntserv/Makefile.in Mon Feb 16 00:14:56 2004 @@ -65,7 +65,7 @@ all: $(PMAKE) ntserv daemonII ntserv: $(PMAKE) $(R_OBJS) - $(CC) $(CFLAGS) ${LDFLAGS} -o ntserv $(R_OBJS) $(LIBS) $(LIBCRYPT) + $(CC) $(CFLAGS) ${LDFLAGS} -o ntserv $(R_OBJS) $(LIBS) $(LIBCRYPT) `glib-config --libs` daemonII: $(PMAKE) $(D_OBJS) $(CC) $(CFLAGS) ${LDFLAGS} -o daemonII $(D_OBJS) $(EXTRALIBS) @@ -74,7 +74,7 @@ $(CC) $(CFLAGS) $(DEP) -c ${srcdir}/commands.c db.o: $(PMAKE) db.c - $(CC) $(CFLAGS) $(DEP) `glib-config --cflags` -c $db.c + $(CC) $(CFLAGS) $(DEP) `glib-config --cflags` -c db.c cflags: echo "static char cflags[]=\"$(CFLAGS) $(LIBS)\";" >../cflags.h _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From quozl at us.netrek.org Mon Feb 16 06:08:43 2004 From: quozl at us.netrek.org (James Cameron) Date: Wed Jan 12 00:50:54 2005 Subject: [Vanilla Devel] Re: Player database problems In-Reply-To: References: <5.2.0.9.0.20040205161749.01cad230@mailgate.team17.com> <5.2.0.9.0.20040205161749.01cad230@mailgate.team17.com> <5.2.0.9.0.20040206105625.038a9ea8@mailgate.team17.com> <20040206215359.GA22736@us.netrek.org> Message-ID: <20040216120843.GB28563@us.netrek.org> Okay, Nick, I tried it. The bots nicely came in and helped out the twinks, but with four on a side no further logins were allowed. Teams "greyed out". Any ideas? It sure helps to add *@`hostname` to .bypass. ;-) By the way, the player index code is now live on continuum. Please log in just to check. ;-} You should not notice any difference, unless you're timing the login confirmation delay. -- James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/ _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From slagerni at msu.edu Mon Feb 16 06:44:20 2004 From: slagerni at msu.edu (Nicholas James Slager) Date: Wed Jan 12 00:50:54 2005 Subject: [Vanilla Devel] Re: Player database problems In-Reply-To: <20040216120843.GB28563@us.netrek.org> References: <5.2.0.9.0.20040205161749.01cad230@mailgate.team17.com> <5.2.0.9.0.20040205161749.01cad230@mailgate.team17.com> <5.2.0.9.0.20040206105625.038a9ea8@mailgate.team17.com> <20040206215359.GA22736@us.netrek.org> <20040216120843.GB28563@us.netrek.org> Message-ID: Sounds like you had "NEWBIE=1" instead of "PRET=1". Different modes, both used bots. If that's not the problem, then there was sometimes a slight delay as the bot you were replacing left the game. Everything would appear greyed out for ~15 seconds. A good way to get people to look at the MOTD :) Nick James Cameron writes: > Okay, Nick, I tried it. The bots nicely came in and helped out the > twinks, but with four on a side no further logins were allowed. > Teams "greyed out". Any ideas? > > It sure helps to add *@`hostname` to .bypass. ;-) > > By the way, the player index code is now live on continuum. Please log > in just to check. ;-} You should not notice any difference, unless > you're timing the login confirmation delay. > > -- > James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/ > > _______________________________________________ > vanilla-devel mailing list > vanilla-devel@us.netrek.org > https://mailman.real-time.com/mailman/listinfo/vanilla-devel > _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From quozl at us.netrek.org Mon Feb 16 15:44:28 2004 From: quozl at us.netrek.org (James Cameron) Date: Wed Jan 12 00:50:54 2005 Subject: [Vanilla Devel] Re: Player database problems In-Reply-To: References: <5.2.0.9.0.20040205161749.01cad230@mailgate.team17.com> <5.2.0.9.0.20040205161749.01cad230@mailgate.team17.com> <5.2.0.9.0.20040206105625.038a9ea8@mailgate.team17.com> <20040206215359.GA22736@us.netrek.org> <20040216120843.GB28563@us.netrek.org> Message-ID: <20040216214428.GA28599@us.netrek.org> Looking back, I had a daemon without pret support running with a new pret binary. I'd started the pret binary. -- James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/ _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From vanilla-devel at us.netrek.org Mon Feb 16 18:21:20 2004 From: vanilla-devel at us.netrek.org (Vanilla CVS Development) Date: Wed Jan 12 00:50:54 2005 Subject: [Vanilla Devel] CVS update: Vanilla Message-ID: <200402170021.i1H0LKw06677@swashbuckler.real-time.com> Date: Monday February 16, 2004 @ 18:21 Author: cameron Update of /home/netrek/cvsroot/Vanilla In directory swashbuckler.real-time.com:/var/tmp/cvs-serv6674 Modified Files: ChangeLog Log Message: add NO_DUPLICATE_HOSTS feature **************************************** Index: Vanilla/ChangeLog diff -u Vanilla/ChangeLog:1.148 Vanilla/ChangeLog:1.149 --- Vanilla/ChangeLog:1.148 Sun Feb 15 19:45:46 2004 +++ Vanilla/ChangeLog Mon Feb 16 18:21:19 2004 @@ -1,3 +1,10 @@ +Tue Feb 16 22:32:11 2004 James Cameron + + * include/config.h.in, include/proto.h, ntserv/main.c, + ntserv/findslot.c (findslot): add NO_DUPLICATE_HOSTS define, add + host to findslot() arguments, to reduce multiple connections from + the same host. + Sun Feb 15 22:47:15 2004 James Cameron * ntserv/db.c, ntserv/Makefile.in, ntserv/Makefile: add database @@ -1516,4 +1523,4 @@ update_sys_defaults in updateMessages to a more appropriate location - updateClient in socket.c. - $Id: ChangeLog,v 1.148 2004/02/16 01:45:46 cameron Exp $ + $Id: ChangeLog,v 1.149 2004/02/17 00:21:19 cameron Exp $ _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From vanilla-devel at us.netrek.org Mon Feb 16 18:21:20 2004 From: vanilla-devel at us.netrek.org (Vanilla CVS Development) Date: Wed Jan 12 00:50:54 2005 Subject: [Vanilla Devel] CVS update: Vanilla/ntserv Message-ID: <200402170021.i1H0LKj06688@swashbuckler.real-time.com> Date: Monday February 16, 2004 @ 18:21 Author: cameron Update of /home/netrek/cvsroot/Vanilla/ntserv In directory swashbuckler.real-time.com:/var/tmp/cvs-serv6674/ntserv Modified Files: findslot.c main.c Log Message: add NO_DUPLICATE_HOSTS feature **************************************** Index: Vanilla/ntserv/findslot.c diff -u Vanilla/ntserv/findslot.c:1.2 Vanilla/ntserv/findslot.c:1.3 --- Vanilla/ntserv/findslot.c:1.2 Fri Apr 30 15:18:43 1999 +++ Vanilla/ntserv/findslot.c Mon Feb 16 18:21:20 2004 @@ -15,6 +15,20 @@ #include "data.h" #include "proto.h" +/* return true if the host is not already in the game */ +static int absent(int w_queue, char *host) { + int i, here = 0; + for (i=0; igameup & GU_GAMEOK)) { return (-1); } + sleep(1); + } + } +#endif + /* If no one is waiting, I will try to enter now */ if (queues[w_queue].first == -1) if ( (i=pickslot(w_queue)) >= 0 ) return (i); @@ -48,6 +75,7 @@ mywait = queue_add(w_queue); /* Get me into the queue */ if (mywait == -1) return (-1); /* The queue is full! */ + rep = 0; oldcount = waiting[mywait].count; for (;;) { Index: Vanilla/ntserv/main.c diff -u Vanilla/ntserv/main.c:1.27 Vanilla/ntserv/main.c:1.28 --- Vanilla/ntserv/main.c:1.27 Sat Aug 23 01:14:19 2003 +++ Vanilla/ntserv/main.c Mon Feb 16 18:21:20 2004 @@ -176,7 +176,8 @@ sendMotd(); - pno = findslot(w_queue); + /* wait for a slot to become free */ + pno = findslot(w_queue, host); if (pno < 0) { /* trigger client's "Sorry, but you cannot play xtrek now. Try again later." */ @@ -186,7 +187,6 @@ sendClientPacket (&packet); flushSockBuf (); ERROR(2,("ntserv/main.c: Quitting: No slot available on queue %d\n",w_queue)); - /* print some appropriate message */ exit(1); } _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From vanilla-devel at us.netrek.org Mon Feb 16 18:21:20 2004 From: vanilla-devel at us.netrek.org (Vanilla CVS Development) Date: Wed Jan 12 00:50:54 2005 Subject: [Vanilla Devel] CVS update: Vanilla/include Message-ID: <200402170021.i1H0LKh06682@swashbuckler.real-time.com> Date: Monday February 16, 2004 @ 18:21 Author: cameron Update of /home/netrek/cvsroot/Vanilla/include In directory swashbuckler.real-time.com:/var/tmp/cvs-serv6674/include Modified Files: config.h.in proto.h Log Message: add NO_DUPLICATE_HOSTS feature **************************************** Index: Vanilla/include/config.h.in diff -u Vanilla/include/config.h.in:1.5 Vanilla/include/config.h.in:1.6 --- Vanilla/include/config.h.in:1.5 Sun Feb 15 19:45:46 2004 +++ Vanilla/include/config.h.in Mon Feb 16 18:21:20 2004 @@ -468,6 +468,15 @@ server. */ #define PLAYER_INDEX + /* NO_DUPLICATE_HOSTS - prevents two + pickup players from the same host, + prevents a player opening an observer + slot, but does not prevent a player + slot being opened by an existing + observer slot. The new client is + given a wait queue response of + MAXPLAYERS. Requires FULL_HOSTNAMES. */ +#define NO_DUPLICATE_HOSTS #endif /* SERVER */ Index: Vanilla/include/proto.h diff -u Vanilla/include/proto.h:1.5 Vanilla/include/proto.h:1.6 --- Vanilla/include/proto.h:1.5 Sat Aug 23 01:14:19 2003 +++ Vanilla/include/proto.h Mon Feb 16 18:21:20 2004 @@ -1,4 +1,4 @@ -/* $Id: proto.h,v 1.5 2003/08/23 06:14:19 cameron Exp $ +/* $Id: proto.h,v 1.6 2004/02/17 00:21:20 cameron Exp $ * * Function prototypes for externally accessed functions. */ @@ -45,7 +45,7 @@ void TellClient(char *typ); /* findslot.c */ -int findslot(int w_queue); +int findslot(int w_queue, char *host); /* gencmds.c */ char *addr_mess(int who, int type); _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From quozl at us.netrek.org Mon Feb 16 19:30:34 2004 From: quozl at us.netrek.org (James Cameron) Date: Wed Jan 12 00:50:54 2005 Subject: [Vanilla Devel] NO_DUPLICATE_HOSTS on Continuum Message-ID: <20040217013034.GC28599@us.netrek.org> I've placed the NO_DUPLICATE_HOSTS feature into production on Continuum and it tests out fine. The way it works is to hold the client back from joining the queue or the game until a previous client from the same IP address exits. The client displays a wait queue of 32. Exceptions to the rule are; - an observer from the same IP address is ignored when a client is joining the game on the normal port. This is so that observers can queue their player client. - only the active slots are checked, not the queue ahead, so an IP can be on the queue in two places if it is not yet in the game, and this could allow a duplicate. If you're already in the game, and you start another client, you will be passed by others not in the game. In the "wait queue 32" state, you are not strictly in a queue at all. The server end of the connection will be polling the player list, waiting for you to free the slot. Once that happens, it will be as if you started the client then. I've yet to find out if this conflicts with the way the PreT robots join, but as I saw a queue for them it seems unlikely. This new check is done on the pickup queues only. INL ports are unaffected. Flames? -- James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/ _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From vanillatrek at yahoo.com Thu Feb 19 16:50:45 2004 From: vanillatrek at yahoo.com (Zach) Date: Wed Jan 12 00:50:54 2005 Subject: [Vanilla Devel] Re: Player database problems In-Reply-To: <001401c3f26b$0ee5ceb0$6400a8c0@jeffhymajrfplv> Message-ID: <20040219225045.39990.qmail@web21110.mail.yahoo.com> I am in favor of pre-T bots I just don't think they should be the default in Vanilla. Zach --- Jeff Nowakowski wrote: > I seem to recall you made a big stink about pre-t bots > not being the default. > > -Jeff __________________________________ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From vanillatrek at yahoo.com Thu Feb 19 16:51:13 2004 From: vanillatrek at yahoo.com (Zach) Date: Wed Jan 12 00:50:55 2005 Subject: [Vanilla Devel] Re: Player database problems In-Reply-To: Message-ID: <20040219225113.62234.qmail@web21102.mail.yahoo.com> --- Nicholas James Slager wrote: > Of course. It's in the main CVS branch. It should be > turned on on all > servers. There's no reason not to. > > Nick I agree. Zach __________________________________ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From vanilla-devel at us.netrek.org Fri Feb 20 13:55:02 2004 From: vanilla-devel at us.netrek.org (Vanilla CVS Development) Date: Wed Jan 12 00:50:55 2005 Subject: [Vanilla Devel] CVS update: metaserver Message-ID: <200402201955.i1KJt2a00637@swashbuckler.real-time.com> Date: Friday February 20, 2004 @ 13:55 Author: unbelver Update of /home/netrek/cvsroot/metaserver In directory swashbuckler.real-time.com:/var/tmp/cvs-serv634 Modified Files: checkalive Log Message: "." is not in my path. That's a good thing. --Carlos V. **************************************** Index: metaserver/checkalive diff -u metaserver/checkalive:1.2 metaserver/checkalive:1.3 --- metaserver/checkalive:1.2 Wed Dec 10 01:40:22 2003 +++ metaserver/checkalive Fri Feb 20 13:55:02 2004 @@ -10,5 +10,5 @@ { print("Starting metaserver\n"); chdir("/home/unbelver/src/metaserver"); - exec("metaserverII -d"); + exec("./metaserverII -d"); } _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From David.Watson at team17.com Mon Feb 23 08:49:41 2004 From: David.Watson at team17.com (David Watson) Date: Wed Jan 12 00:50:55 2005 Subject: [Vanilla Devel] Recent updates In-Reply-To: <200402201955.i1KJt2a00637@swashbuckler.real-time.com> Message-ID: <5.2.0.9.0.20040223143121.02d94c00@mailgate.team17.com> Player database works on a newly compiled server (from cvs), I had to provide glib and gdbm which were not required before. I also had to edit system.mk and add gdbm to extralibs giving: EXTRALIBS = $(LINKFLAGS) -lnsl -lm -lgdbm NO_DUPLICATE_HOSTS kills PreT for me. (one robot comes on), I'm not sure why you think it might not kill them as they connect like clients? an exception for 127.0.0.1 isn't even enough (for me) as my linux distro connects back with a source address of its ip rather than local. I'm happy to disable the feature for now in any case just thought it was worth mentioning. Should something like this be in .sysdef? perhaps with an exception list? all very well for me to say things like that when I cant code ;) Pathetically I havnt done much on my server so I'll take a look at my metaserver problems today and see if I cant get things online properly Dave PS. What's the best way to shutdown a running server? _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From David.Watson at team17.com Mon Feb 23 11:23:19 2004 From: David.Watson at team17.com (David Watson) Date: Wed Jan 12 00:50:55 2005 Subject: [Vanilla Devel] Solicit metaserver problems In-Reply-To: <5.2.0.9.0.20040223143121.02d94c00@mailgate.team17.com> References: <200402201955.i1KJt2a00637@swashbuckler.real-time.com> Message-ID: <5.2.0.9.0.20040223165720.037ea8b8@mailgate.team17.com> The problems I'm having with the metaserver solicitation seems to be down to the fact that I am running the server behind a network address translation firewall which causes solicit to fail to bind to an ip address. My solution was to add the name that I am using in the metaservers file (eurotwinks.team17.com) into the /etc/hosts so that locally the address points to the private IP but everyone else resolves it to the public IP. This seems to work. I've now run into a problem with PreT itself though, the bots start up as player 1 begins to join, but when the game is (4 bots) v (3 bots and player) no-one new can join (all teams greyed out) Anyone run into this before? By the way is there an ongoing problem with continuum? I'd like to get a new netrek.org name for this server, something like practice.eu.netrek.org or training or something, does that sound sensible? Cheers ______________________________________________________________ David Watson, Network Manager, Team17 Software Ltd. Phone: +44-1924-267776 Fax: +44-1924-267658 Cellular: +44-777-1793298 ______________________________________________________________ _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From quozl at us.netrek.org Mon Feb 23 15:39:36 2004 From: quozl at us.netrek.org (James Cameron) Date: Wed Jan 12 00:50:55 2005 Subject: [Vanilla Devel] Recent updates In-Reply-To: <5.2.0.9.0.20040223143121.02d94c00@mailgate.team17.com> References: <200402201955.i1KJt2a00637@swashbuckler.real-time.com> <5.2.0.9.0.20040223143121.02d94c00@mailgate.team17.com> Message-ID: <20040223213936.GA9995@us.netrek.org> On Mon, Feb 23, 2004 at 02:49:41PM +0000, David Watson wrote: > Player database works on a newly compiled server (from cvs), I had > to provide glib and gdbm which were not required before. I also had to edit > system.mk and add gdbm to extralibs giving: > EXTRALIBS = $(LINKFLAGS) -lnsl -lm -lgdbm Thanks. Ideally configure should find this out but my change had not progressed to that stage. If you have patched for configure.in, please let us know. > NO_DUPLICATE_HOSTS kills PreT for me. (one robot comes on), I'm not sure > why you think it might not kill them as they connect like clients? Yes, NO_DUPLICATE_HOSTS is currently incompatible with PreT robots, and I'll change the default in config.h.in in CVS. Yes, an exception list is probably a good idea. There's at least two players that I know of who connect through a common firewall. > PS. What's the best way to shutdown a running server? Kill the daemon, normal kill. Avoid -9, as it may leave the memory segment around. Kill the netrekd. -- James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/ _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From quozl at us.netrek.org Mon Feb 23 15:42:23 2004 From: quozl at us.netrek.org (James Cameron) Date: Wed Jan 12 00:50:55 2005 Subject: [Vanilla Devel] Solicit metaserver problems In-Reply-To: <5.2.0.9.0.20040223165720.037ea8b8@mailgate.team17.com> References: <200402201955.i1KJt2a00637@swashbuckler.real-time.com> <5.2.0.9.0.20040223165720.037ea8b8@mailgate.team17.com> Message-ID: <20040223214223.GB9995@us.netrek.org> On Mon, Feb 23, 2004 at 05:23:19PM +0000, David Watson wrote: > My solution was to add the name that I am using in the metaservers file > (eurotwinks.team17.com) into the /etc/hosts so that locally the address > points to the private IP but everyone else resolves it to the public IP. > This seems to work. Yes, that would do it. > I've now run into a problem with PreT itself though, the bots start up as > player 1 begins to join, but when the game is (4 bots) v (3 bots and > player) no-one new can join (all teams greyed out) > Anyone run into this before? Yes, I got this the first time I tried PreT on continuum. I've not yet figured out what causes it, and it is preventing deployment on continuum. > By the way is there an ongoing problem with continuum? Nobody has told me there is one. Oh, apart from social problems. > I'd like to get a new netrek.org name for this server, something like > practice.eu.netrek.org or training or something, does that sound sensible? Sure. -- James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/ _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From Shadow.Hunter at netrek.org Tue Feb 24 12:04:35 2004 From: Shadow.Hunter at netrek.org (E. Hietbrink) Date: Wed Jan 12 00:50:55 2005 Subject: [Vanilla Devel] Solicit metaserver problems In-Reply-To: <5.2.0.9.0.20040223165720.037ea8b8@mailgate.team17.com> References: <200402201955.i1KJt2a00637@swashbuckler.real-time.com> <5.2.0.9.0.20040223165720.037ea8b8@mailgate.team17.com> Message-ID: <403B9233.1070907@netrek.org> David Watson wrote: > > The problems I'm having with the metaserver solicitation seems to be > down to the fact that I am running the server behind a network address > translation firewall which causes solicit to fail to bind to an ip address. > > My solution was to add the name that I am using in the metaservers file > (eurotwinks.team17.com) into the /etc/hosts so that locally the address > points to the private IP but everyone else resolves it to the public IP. > This seems to work. > Anyone run into this before? Older thread: http://archives.real-time.com/pipermail/vanilla-metaserver/2003-June/000224.html I removed the bind call in my server code eventually, but your solutions seems better. Greetx, Erik _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From quozl at us.netrek.org Wed Feb 25 02:38:58 2004 From: quozl at us.netrek.org (James Cameron) Date: Wed Jan 12 00:50:55 2005 Subject: [Vanilla Devel] Infrequent stats updates Message-ID: <20040225083858.GA14641@us.netrek.org> A player has commented that the recent change on continuum has resulted in very delayed stats updates on the player list. I've seen a similar symptom myself, and I did a packet trace (using cow client's -P, thanks to Carlos), and indeed the stats updates are very infrequent. genspkt.c is at rev 1.28 from CVS (HEAD). I reviewed the changes, and I had upgraded continuum from 1.20. I think I had continuum at 1.20 for a similar reason. I've reviewed the diffs, and nothing springs out as the cause, and when I run 1.28 on my test environment I see a quite regular SP_STATS update. Any ideas? -- James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/ _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From slagerni at msu.edu Thu Feb 26 08:04:21 2004 From: slagerni at msu.edu (Nicholas James Slager) Date: Wed Jan 12 00:50:55 2005 Subject: [Vanilla Devel] Re: Solicit metaserver problems In-Reply-To: <20040223214223.GB9995@us.netrek.org> References: <200402201955.i1KJt2a00637@swashbuckler.real-time.com> <5.2.0.9.0.20040223165720.037ea8b8@mailgate.team17.com> <20040223214223.GB9995@us.netrek.org> Message-ID: I fired up the server on my linux box (where I did the initial development) and had no problems. Sometimes there is a slight delay where all teams are greyed out while a bot leaves the game, but I've never seen it be more then maybe 10 seconds. Perhaps it's a client issue where the client isn't updating when the team becomes available? On the client that is connected, does a bot leave? I use an old paradise client to do all my testing of pre-t if that makes a difference. James Cameron writes: > On Mon, Feb 23, 2004 at 05:23:19PM +0000, David Watson wrote: >> My solution was to add the name that I am using in the metaservers file >> (eurotwinks.team17.com) into the /etc/hosts so that locally the address >> points to the private IP but everyone else resolves it to the public IP. >> This seems to work. > > Yes, that would do it. > >> I've now run into a problem with PreT itself though, the bots start up as >> player 1 begins to join, but when the game is (4 bots) v (3 bots and >> player) no-one new can join (all teams greyed out) >> Anyone run into this before? > > Yes, I got this the first time I tried PreT on continuum. I've not yet > figured out what causes it, and it is preventing deployment on continuum. > _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From David.Watson at team17.com Thu Feb 26 09:25:13 2004 From: David.Watson at team17.com (David Watson) Date: Wed Jan 12 00:50:55 2005 Subject: [Vanilla Devel] PreT In-Reply-To: References: <20040223214223.GB9995@us.netrek.org> <200402201955.i1KJt2a00637@swashbuckler.real-time.com> <5.2.0.9.0.20040223165720.037ea8b8@mailgate.team17.com> <20040223214223.GB9995@us.netrek.org> Message-ID: <5.2.0.9.0.20040226141430.01cf0648@mailgate.team17.com> On my server the bots don't leave (ever), you can get more players by joining before all the bots start up but they just don't leave. I guess Nick's server is his patch to the CVS of the time and something has changed since then that stops the bots quitting. Perhaps Nick could try a server fresh out of CVS? I tried messing about with the debug, debugTarget and debugLevel variables in pret.c but I've no idea what I'm doing and cant get stop_a_robot() to put out any information as to if its called, and how far it goes if it is. If you want to look at my server its on eurotwinks.netrek.org 2592 Sorry I couldnt fathom how to debug, same goes for configure.in, learning to program a proper language is always on my list of things to do but.... Dave _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From quozl at us.netrek.org Thu Feb 26 17:17:37 2004 From: quozl at us.netrek.org (James Cameron) Date: Wed Jan 12 00:50:55 2005 Subject: [Vanilla Devel] Re: Solicit metaserver problems In-Reply-To: References: <200402201955.i1KJt2a00637@swashbuckler.real-time.com> <5.2.0.9.0.20040223165720.037ea8b8@mailgate.team17.com> <20040223214223.GB9995@us.netrek.org> Message-ID: <20040226231737.GB12946@us.netrek.org> I haven't tried looking yet, but which line of code causes a robot to want to leave when there is a queue? But how is that relevant? Somehow even with four robots and no human players, anyone else who joins gets a slot but the team boxes are greyed out. As if the maximum number of players allowed on the team has been set to four? -- James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/ _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From David.Watson at team17.com Fri Feb 27 05:04:00 2004 From: David.Watson at team17.com (David Watson) Date: Wed Jan 12 00:50:55 2005 Subject: [Vanilla Devel] Re: Solicit metaserver problems In-Reply-To: <20040226231737.GB12946@us.netrek.org> References: <200402201955.i1KJt2a00637@swashbuckler.real-time.com> <5.2.0.9.0.20040223165720.037ea8b8@mailgate.team17.com> <20040223214223.GB9995@us.netrek.org> Message-ID: <5.2.0.9.0.20040227105552.03bb4eb8@mailgate.team17.com> I believe that PreT is always 4v4 so there is a limit (not sure why it is needed) On a working preT server you do see the teams greyed out before a bot quits leaving a slot open for you to join. once you reach the minimum for T then preT ends and you can progress up to a full game... Certainly the bots are not quitting out at any time, either when a human wants in or after preT times out with no players. To my uneducated eye it looks like the bots slot is freed in order to get it out? Its the pret bot that manages this (robots/pret.c) and the function given below static void stop_a_robot(void) { int i; struct player *j; int teamToStop; if(debugTarget != -1 && debugLevel == 3) { messOne(255, roboname, debugTarget, "#1(%d): %d #2(%d): %d", team1, num_humans(team1), team2, num_humans(team2)); } if(num_humans(team1) < num_humans(team2)) teamToStop = team1; else teamToStop = team2; if(debugTarget != -1 && debugLevel == 3) { messOne(255, roboname, debugTarget, "Stopping from %d", teamToStop); } /* Nuke robot from the team with the fewest humans. */ for (i = 0, j = players; i < MAXPLAYER; i++, j++) { if (j->p_status == PFREE) continue; if (j->p_flags & PFROBOT) continue; /* If he's at the MOTD we'll get him next time. */ if (j->p_team == teamToStop && j->p_status == PALIVE && rprog(j->p_login, j->p_full_hostname)) { stop_this_bot(j); return; } } } _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From quozl at us.netrek.org Mon Feb 16 19:30:34 2004 From: quozl at us.netrek.org (James Cameron) Date: Wed Jan 12 00:51:54 2005 Subject: [Vanilla List] NO_DUPLICATE_HOSTS on Continuum Message-ID: <20040217013034.GC28599@us.netrek.org> I've placed the NO_DUPLICATE_HOSTS feature into production on Continuum and it tests out fine. The way it works is to hold the client back from joining the queue or the game until a previous client from the same IP address exits. The client displays a wait queue of 32. Exceptions to the rule are; - an observer from the same IP address is ignored when a client is joining the game on the normal port. This is so that observers can queue their player client. - only the active slots are checked, not the queue ahead, so an IP can be on the queue in two places if it is not yet in the game, and this could allow a duplicate. If you're already in the game, and you start another client, you will be passed by others not in the game. In the "wait queue 32" state, you are not strictly in a queue at all. The server end of the connection will be polling the player list, waiting for you to free the slot. Once that happens, it will be as if you started the client then. I've yet to find out if this conflicts with the way the PreT robots join, but as I saw a queue for them it seems unlikely. This new check is done on the pickup queues only. INL ports are unaffected. Flames? -- James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/ _______________________________________________ vanilla-list mailing list vanilla-list@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-list