From vanilla-clients-admin at archives.real-time.com Wed Jan 12 00:50:03 2005 From: vanilla-clients-admin at archives.real-time.com (vanilla-clients-admin@archives.real-time.com) Date: Wed Jan 12 00:50:08 2005 Subject: [Netrek Clients] Interest Calculator for Lawyers Message-ID: 21696099638938.62668.qmail@bellsouth.net Have you ever been in this situation? You are representing a client who is supposed to receive a monthly payment. On some months, that payment has been made on time, but on other months it has been paid late and often not at all. Your client is entitled to interest on amounts owing, but figuring out how much interest precisely is another matter. In these situations, our Interest Wizard can reliably help you determine the correct amounts owed. Whether your client is owed Child Support, Rent, or any judgment or debt payable in monthly, weekly, or yearly installments, our Interest Wizard can help you calculate what's owed and generate a professional looking report to attach to a court filing. Simply enter the monthly obligation and any payments actually received. Click on the Calculate button and you have a chart reflecting the total obligation owed, every payment actually received, the amount due after each payment, and the accrued interest. When you're done, you can print your chart and save the file under your client's name. Give our Interest Wizard a try today. It's just $69.95, and it's guaranteed to satisfy or your money back. To place an order, visit our website at: http://www.ThorpeForms.com/lib/mrktAds.php?ad=iwiz022003 Join the thousands of attorneys that already use our legal software! Thank you for your time. Sincerely, David James Thorpe, Esq. Offices of David Thorpe Legal Software * To be removed from this mailing list please visit http://www.thorpeforms.com/mlist.php. From ThorpeForms at bellsouth.net Wed Jan 12 00:50:03 2005 From: ThorpeForms at bellsouth.net (David James Thorpe JD) Date: Wed Jan 12 00:50:10 2005 Subject: [Netrek Clients] Interest Calculator for Lawyers Message-ID: 21696099638938.62668.qmail@bellsouth.net Have you ever been in this situation? You are representing a client who is supposed to receive a monthly payment. On some months, that payment has been made on time, but on other months it has been paid late and often not at all. Your client is entitled to interest on amounts owing, but figuring out how much interest precisely is another matter. In these situations, our Interest Wizard can reliably help you determine the correct amounts owed. Whether your client is owed Child Support, Rent, or any judgment or debt payable in monthly, weekly, or yearly installments, our Interest Wizard can help you calculate what's owed and generate a professional looking report to attach to a court filing. Simply enter the monthly obligation and any payments actually received. Click on the Calculate button and you have a chart reflecting the total obligation owed, every payment actually received, the amount due after each payment, and the accrued interest. When you're done, you can print your chart and save the file under your client's name. Give our Interest Wizard a try today. It's just $69.95, and it's guaranteed to satisfy or your money back. To place an order, visit our website at: http://www.ThorpeForms.com/lib/mrktAds.php?ad=iwiz022003 Join the thousands of attorneys that already use our legal software! Thank you for your time. Sincerely, David James Thorpe, Esq. Offices of David Thorpe Legal Software * To be removed from this mailing list please visit http://www.thorpeforms.com/mlist.php. From vanillatrek at yahoo.com Tue Jan 4 04:42:14 2005 From: vanillatrek at yahoo.com (Zach) Date: Wed Jan 12 00:50:17 2005 Subject: [Netrek Clients] Clients not blessed Message-ID: <20050104104214.65651.qmail@web21126.mail.yahoo.com> Hello, I can't seem to find any BRMH 2.4 or Paradise RC3 binaries that are blessed for pickled.psychosis.net I downloaded the binaries from ftp.netrek.org The BRMH 2.4 binaries either ghostbust write away or complain about not finding mpz_init() :( The Paradise RC3 client just says that "This is not a blessed client." So far the ONLY linux client I've found that works on pickled is the Paradise 2.99 FINAL client ! Heeeeeelp! I've not the only one with this problem. Recently Nimret was having same issues with BRMH 2.4 as well. I'd gladly do a fresh compile if someone will put them up on ftp.netrek.org I've mailed Karth several times but have received no replies in the past several months regarding this issue. Regards, Zach __________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com _______________________________________________ vanilla-clients mailing list vanilla-clients@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-clients From msucka0xff at programmer.net Tue Jan 4 16:30:00 2005 From: msucka0xff at programmer.net (. .) Date: Wed Jan 12 00:50:17 2005 Subject: [Netrek Clients] Re: [Vanilla Devel] Clients not blessed Message-ID: <20050104223000.62FBB1F50B1@ws1-2.us4.outblaze.com> >The BRMH 2.4 binaries either ghostbust write away or >complain about not finding mpz_init() :( Zach, You prolly need libgmp. Apt get gmp for debian. See if you don't already have that package installed. If not, I would suspect that the RSA key is OK, but that the lack of gmp code causes the large integer operations to fail. ldd your client to see how it is resolving its symbols. Check to see libgmp.so or libgmp.a exists, along with the other libs. -bd -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm _______________________________________________ vanilla-clients mailing list vanilla-clients@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-clients From msucka0xff at programmer.net Wed Jan 5 09:20:02 2005 From: msucka0xff at programmer.net (. .) Date: Wed Jan 12 00:50:17 2005 Subject: [Netrek Clients] Clients not blessed Message-ID: <20050105152003.8D20C6F027@ws1-5.us4.outblaze.com> ----- Original Message ----- From: Zach > I can't seem to find any BRMH 2.4 or Paradise RC3 > binaries that are blessed for pickled.psychosis.net > > The BRMH 2.4 binaries either ghostbust write away or > complain about not finding mpz_init() :( mpz_init symbol has changed to gmpz_init, u may need to recompile your libgmp (unless recompile the src with the key). I feel confident saying that the RSA key is more than likely good even though I don't know which one it uses. Try checking the command line options to see if it prints this info out, then check to see if it's on the metaserver's list. -bd p.s. try a statically linked version -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm _______________________________________________ vanilla-clients mailing list vanilla-clients@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-clients From Shadow.Hunter at netrek.org Thu Jan 6 07:51:56 2005 From: Shadow.Hunter at netrek.org (E. Hietbrink) Date: Wed Jan 12 00:50:17 2005 Subject: [Netrek Clients] Re: Need Help Busting Netrek-threatening Patent Message-ID: <41DD427C.1020606@netrek.org> FYI, I received a request to bust some patent with prior art: Netrek.I remember things like this popping up before in the past. Who handled it back then and what was it about? Anyway, find below a quick draft of my answer to Nick Schuneman. Can you guys go over it and correct/extend where appropriate? I do not know all the answers. Let's try to give him a prompt response. I do not want to ask the guy this now, but I'd like to know how we can *prove* that the features we discuss were present in Netrek/Xtrek in the 80's? Anyone still has CVS logfiles? Or what methods could we use for that? Further: is it normal to not disclose further details of the conflicting patent? Regards, Erik > Date: Wed, 5 Jan 2005 15:57:36 -0500 > From: nschunem@law.harvard.edu > To: Shadow.Hunter@netrek.org > Subject: Need Help Busting Netrek-threatening Patent > > Hello, > > My name is Nick Schuneman. I am a second year law student at Harvard, and am > working this winter on a project to "bust" (i.e. invalidate) > technology-constricting patents. A noble cause indeed! > One of the patents we are trying to > invalidate seemingly covers games like Netrek, and if upheld as valid by the > Patent Office, could be used to enjoin Netrek players from enjoying their > favorite pastime and even sue Netrek users and developers for monetary damages. > In fact, the patent owner has already shown a propensity for threatening > small-time and non-profit operations that he feels infringe his patent. It it possible for you to disclose more information about the patent in question? Out of curiosity (obviously I am not a lawyer), but Netrek has always been open source and never required any fees to play, and never pushed other competing games out of the market, so how could anyone sue for monetary damages in that case? > However, there is some good news. Netrek was developed prior to the critical > date of the patent (which dates back to 1996), and therefore may help to bust > the patent and protect the innovative activities of those in the on-line gaming > community. I have read the Netrek FAQ and Newbie guide, and have compiled a > good deal of information that will be helpful in busting the patent at issue. > But I still have a few blanks that I hope you could help fill in (or at least > point me in the right direction). Any information you an provide would be of > great help in our effort to prevent bullying of community-minded software > developers. Netrek in its current form was born in 1988, so that should adequately predate this patent. But many of the game features that you inquire are even present in Netrek's direct predecessors, Xtrek, Conquest and Empire, dating back to the early 80's. > Please bear in mind that I'm not a gamer, so I apologize if I use any > inappropriate or absurd vocabulary to describe certain features of the game. > > (1) How often are the ratings / rankings updated? Question to you all: is this per server tick? =10 times per second? > (2) Are the rankings of other players transmitted (and displayed) to each player > during the game play? Yes, both transmitted and displayed during game play. Outside the game the statistics overview can be generated at arbitrary intervals. > (3) Can players log on / log off of a game while other players continue to > play? Yes. There is no requirement for all players to be present before a game can start. They can come and go as they please. A minimum of 4 players on 2 teams is required however to start "Tournament mode" which is the game phase where statistics and rankings are updated. > (4) I read in the FAQ that rankings are only compiled in the "tournament mode." > Is it possible for players to log on and off during the tournament mode game > while other players continue to play? See my answer to (3). At all times it is possible for players to join and leave the game. The latter can also happen unintentionally when a network connection between the server and the player is broken. The game server detects this and cleans up the "slot" for a new player. At most the game server allows 16 concurrent players. When there are more interested players, they will be put into a waiting queue from which they can join the game as soon as a slot opens. > Thank you so much for your help! If you are interested in any further > information regarding the patent-busting project, there is a nice explanation > on the Electronic Frontier Foundation's website: > > http://www.eff.org/patent/wanted/patent.php?p=sheldon > > Thank you, > > Nick Schuneman > > Clinical Student > Berkman Center for Internet & Society > Harvard Law School > nschunem@law.harvard.edu _______________________________________________ vanilla-clients mailing list vanilla-clients@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-clients From ahn at orion.netrek.org Thu Jan 6 10:44:32 2005 From: ahn at orion.netrek.org (Dave Ahn) Date: Wed Jan 12 00:50:17 2005 Subject: [Netrek Clients] Re: [Vanilla Devel] Re: Need Help Busting Netrek-threatening Patent In-Reply-To: <41DD427C.1020606@netrek.org> References: <41DD427C.1020606@netrek.org> Message-ID: <20050106164432.GA23511@orion.netrek.org> The previous case was Lipstream vs HearMe. This IP law suit was settled due to prior art in Netrek. Unfortunately the patent itself was not overturned. A number of key netrek contributors were involved in this law suit including myself. I have a copy of the motion for summary judgment at www.netrek.org/archive/patent/SJ_Motion.pdf which is available to the netrek community as a result of our help. I do not know if the settlement itself was sealed. If you search vanilla-list, there should be some archived messages about this issue. Dave On Thu, Jan 06, 2005 at 02:51:56PM +0100, E. Hietbrink wrote: > FYI, I received a request to bust some patent with prior art: Netrek.I > remember > things like this popping up before in the past. Who handled it back then and > what was it about? > > Anyway, find below a quick draft of my answer to Nick Schuneman. Can you > guys > go over it and correct/extend where appropriate? I do not know all the > answers. > Let's try to give him a prompt response. > > I do not want to ask the guy this now, but I'd like to know how we can > *prove* > that the features we discuss were present in Netrek/Xtrek in the 80's? > Anyone > still has CVS logfiles? Or what methods could we use for that? > > Further: is it normal to not disclose further details of the conflicting > patent? > > Regards, > Erik > > > > > >Date: Wed, 5 Jan 2005 15:57:36 -0500 > >From: nschunem@law.harvard.edu > >To: Shadow.Hunter@netrek.org > >Subject: Need Help Busting Netrek-threatening Patent > > > >Hello, > > > >My name is Nick Schuneman. I am a second year law student at Harvard, and > >am > >working this winter on a project to "bust" (i.e. invalidate) > >technology-constricting patents. > > A noble cause indeed! > > > >One of the patents we are trying to > >invalidate seemingly covers games like Netrek, and if upheld as valid by > >the > >Patent Office, could be used to enjoin Netrek players from enjoying their > >favorite pastime and even sue Netrek users and developers for monetary > >damages. > > In fact, the patent owner has already shown a propensity for threatening > >small-time and non-profit operations that he feels infringe his patent. > > It it possible for you to disclose more information about the patent in > question? > Out of curiosity (obviously I am not a lawyer), but Netrek has always been > open > source and never required any fees to play, and never pushed other competing > games out of the market, so how could anyone sue for monetary damages in > that > case? > > > >However, there is some good news. Netrek was developed prior to the > >critical > >date of the patent (which dates back to 1996), and therefore may help to > >bust > >the patent and protect the innovative activities of those in the on-line > >gaming > >community. I have read the Netrek FAQ and Newbie guide, and have compiled > >a > >good deal of information that will be helpful in busting the patent at > >issue. But I still have a few blanks that I hope you could help fill in > >(or at least > >point me in the right direction). Any information you an provide would be > >of > >great help in our effort to prevent bullying of community-minded software > >developers. > > Netrek in its current form was born in 1988, so that should adequately > predate > this patent. But many of the game features that you inquire are even present > in Netrek's direct predecessors, Xtrek, Conquest and Empire, dating back to > the > early 80's. > > > >Please bear in mind that I'm not a gamer, so I apologize if I use any > >inappropriate or absurd vocabulary to describe certain features of the > >game. > > > >(1) How often are the ratings / rankings updated? > > Question to you all: is this per server tick? =10 times per second? > > > >(2) Are the rankings of other players transmitted (and displayed) to each > >player > >during the game play? > > Yes, both transmitted and displayed during game play. Outside the game the > statistics overview can be generated at arbitrary intervals. > > > >(3) Can players log on / log off of a game while other players continue to > >play? > > Yes. There is no requirement for all players to be present before a game can > start. They can come and go as they please. A minimum of 4 players on 2 > teams > is required however to start "Tournament mode" which is the game phase where > statistics and rankings are updated. > > > >(4) I read in the FAQ that rankings are only compiled in the "tournament > >mode." Is it possible for players to log on and off during the tournament > >mode game > >while other players continue to play? > > See my answer to (3). At all times it is possible for players to join and > leave > the game. The latter can also happen unintentionally when a network > connection > between the server and the player is broken. The game server detects this > and > cleans up the "slot" for a new player. At most the game server allows 16 > concurrent players. When there are more interested players, they will be put > into a waiting queue from which they can join the game as soon as a slot > opens. > > > >Thank you so much for your help! If you are interested in any further > >information regarding the patent-busting project, there is a nice > >explanation > >on the Electronic Frontier Foundation's website: > > > >http://www.eff.org/patent/wanted/patent.php?p=sheldon > > > >Thank you, > > > >Nick Schuneman > > > >Clinical Student > >Berkman Center for Internet & Society > >Harvard Law School > >nschunem@law.harvard.edu > > > > > _______________________________________________ > vanilla-devel mailing list > vanilla-devel@us.netrek.org > https://mailman.real-time.com/mailman/listinfo/vanilla-devel _______________________________________________ vanilla-clients mailing list vanilla-clients@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-clients From 007 at freemail.at Thu Jan 6 11:21:04 2005 From: 007 at freemail.at (Kurt Siegl) Date: Wed Jan 12 00:50:17 2005 Subject: [Netrek Clients] Re: Need Help Busting Netrek-threatening Patent In-Reply-To: <41DD427C.1020606@netrek.org> References: <41DD427C.1020606@netrek.org> Message-ID: <200501061821.05385.007@freemail.at> On Thursday 06 January 2005 14:51, E. Hietbrink wrote: > I do not want to ask the guy this now, but I'd like to know how we can > *prove* that the features we discuss were present in Netrek/Xtrek in the > 80's? Anyone still has CVS logfiles? Or what methods could we use for that? What I found quickly is an old CD of mine when I left university, which contains as oldest source distribution the calvin-2.2pl3.tar.gz Server and BRM.3.00pl3.tar.gz Client both with all the timestamps from 1993 which is enough for that purpose. I might try to get the bronco sources from somewhere or maybe Tom will find some archive with berkely server code. But anyway, I think the bronco code is the oldest modern Netrek server available. But wait, I just found the oldest RSA server code. Probably bronco code. rsa.netrek.tar.Z The archive has been created on 1993-01-18 :-) Kurt -- Kurt Siegl / Franzberg 4, A-4483 Hargelsberg, Austria Email: Kurt.Siegl@hargelsberg.at Tel (ISDN): *(7225)7017 URL: http://www.hargelsberg.at/siegl/kurt/ _______________________________________________ vanilla-clients mailing list vanilla-clients@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-clients From ahn at orion.netrek.org Thu Jan 6 12:10:06 2005 From: ahn at orion.netrek.org (Dave Ahn) Date: Wed Jan 12 00:50:17 2005 Subject: [Vanilla Devel] Re: [Netrek Clients] Re: Need Help Busting Netrek-threatening Patent In-Reply-To: <200501061821.05385.007@freemail.at> References: <41DD427C.1020606@netrek.org> <200501061821.05385.007@freemail.at> Message-ID: <20050106181006.GA23965@orion.netrek.org> On Thu, Jan 06, 2005 at 06:21:04PM +0100, Kurt Siegl wrote: > On Thursday 06 January 2005 14:51, E. Hietbrink wrote: > > I do not want to ask the guy this now, but I'd like to know how we can > > *prove* that the features we discuss were present in Netrek/Xtrek in the > > 80's? Anyone still has CVS logfiles? Or what methods could we use for that? > > What I found quickly is an old CD of mine when I left university, which > contains as oldest source distribution the The timestamps from CD's don't matter much because Netrek was so widely distributed from early on. There are court documents that include signed declarations that Netrek dates back to the 80's, and a google search shows 136,000 results from numerous independent web sites with time stamps. The question of "when" cannot be refuted, so the only thing that remains is the question of relevance. That is, does Netrek implement ideas that are substantially similar to the patent claims so as to invalidate those claims based on prior art. I didn't look at the 879 patent, so I couldn't say. _______________________________________________ vanilla-clients mailing list vanilla-clients@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-clients From jrd at gerdesas.com Thu Jan 6 09:29:11 2005 From: jrd at gerdesas.com (jrd@gerdesas.com) Date: Wed Jan 12 00:50:17 2005 Subject: [Netrek Clients] Re: [Vanilla Devel] Re: Need Help Busting Netrek-threatening Patent In-Reply-To: <41DD427C.1020606@netrek.org> from "E. Hietbrink" at Jan 06, 2005 02:51:56 PM Message-ID: <20050106152911.13322.qmail@gerdesas.gerdesas.com> In previous mail, E. Hietbrink spouted... > > Netrek in its current form was born in 1988, so that should adequately predate > this patent. But many of the game features that you inquire are even present > in Netrek's direct predecessors, Xtrek, Conquest and Empire, dating back to the > early 80's. I am looking at title page of the original version of 'empire' at the moment, the game that all these derive from. "Copyright 1977, 78, 83 -- by Charles Miller and Gary Fritz" I can get you contact information for Miller if you'd like - I have no idea with Fritz has been for the past 20+ years, tho. This is not being sent to Nick - if you want to forward it on, please feel free. John -- "I'm sorry but our engineers do not have phones." As stated by a Network Solutions Customer Service representative when asked to put me through to an engineer. "My other computer is your windows box." Ralf Hildebrandt _______________________________________________ vanilla-clients mailing list vanilla-clients@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-clients From unbelver at us.netrek.org Thu Jan 6 15:48:02 2005 From: unbelver at us.netrek.org (Carlos Y. Villalpando) Date: Wed Jan 12 00:50:18 2005 Subject: [Netrek Clients] Re: [Vanilla Devel] Re: Need Help Busting Netrek-threatening Patent In-Reply-To: <20050106164432.GA23511@orion.netrek.org> References: <41DD427C.1020606@netrek.org> <20050106164432.GA23511@orion.netrek.org> Message-ID: <20050106214802.GA3051@brain.jpl.nasa.gov> Quoting Dave Ahn : > A number of key netrek contributors were involved in this law suit > including myself. Dave and I were interviewed by the defendant's IP attourneys vi e-mail and face to face during the Spring/Summer of 2000. We showed them what the game was, how it worked, and the technical background of the game and code overview. I was interviewed for about 4 hours or so at my home and I gave them an explanation of the game as it related to the Plaintiff's patent claims. The pdf Dave gave a link to does a good job describing what the patent claims were about and how Netrek related. After they were done with Dave and I, they were extremely excited, so we pointed them to the Netrek history Gurus and founders for the authoritative "Yes, this was going on before the patent was filed" statements, (Kevin Smith, et al.) They apparently got the declarations they needed from them. Afterwards, I was interviewed again for about 2 hours as a final loose end wrap-up. I got a nice dinner out of that one. We asked for, and received permission to do a Slashdot story along the lines of "Netrek helps kill a stupid patent", but I believe we decided not to when we heard the case was settled instead of having the patent invalidated. Since the patent was still in force, we thought it best to lay low since they could come after Netrek. > If you search vanilla-list, there should be some archived messages > about this issue. Dave, after the initial query by Chawla and the initial responses, you, James, and I decided to not tell the rest of the Netrek community what was going on after we found out who the interested parties were. So there's not much on the vanilla-l archive. Most of our discussions were via IRC, though we did have some e-mail interactions. For some odd reason, I didn't save my half of the emails, just you quoting me. --Carlos V. _______________________________________________ vanilla-clients mailing list vanilla-clients@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-clients From ahn at orion.netrek.org Thu Jan 6 17:04:56 2005 From: ahn at orion.netrek.org (Dave Ahn) Date: Wed Jan 12 00:50:18 2005 Subject: [Netrek Clients] Re: [Vanilla Devel] Re: Need Help Busting Netrek-threatening Patent In-Reply-To: <20050106214802.GA3051@brain.jpl.nasa.gov> References: <41DD427C.1020606@netrek.org> <20050106164432.GA23511@orion.netrek.org> <20050106214802.GA3051@brain.jpl.nasa.gov> Message-ID: <20050106230456.GA25215@orion.netrek.org> On Thu, Jan 06, 2005 at 01:48:02PM -0800, Carlos Y. Villalpando wrote: > > Dave, after the initial query by Chawla and the initial responses, > you, James, and I decided to not tell the rest of the Netrek community > what was going on after we found out who the interested parties > were. So there's not much on the vanilla-l archive. I'm getting old and forgetful. I could have sworn I posted something to the lists. Anyway, I did get permission to publish the motion document to the community. It's a good read on how patent claims are contested. _______________________________________________ vanilla-clients mailing list vanilla-clients@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-clients From ahn at orion.netrek.org Fri Jan 7 18:18:46 2005 From: ahn at orion.netrek.org (Dave Ahn) Date: Wed Jan 12 00:50:18 2005 Subject: [Netrek Clients] expired and non-working clients Message-ID: <20050108001846.GA1954@orion.netrek.org> It looks like numerous clients have expired and/or are defunct. I am going to retire them and release a limited batch of new clients compiled from the latest sources using SourceForge's compile farm. Carlos, I'm going to send you some new keys soon. I'll also bring back an INL server on orion. See upcoming announcement for details. Dave _______________________________________________ vanilla-clients mailing list vanilla-clients@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-clients From kbernatz at excite.com Fri Jan 7 09:30:18 2005 From: kbernatz at excite.com (Kevin Bernatz) Date: Wed Jan 12 00:50:18 2005 Subject: Fwd: [Netrek Clients] Re: Need Help Busting Netrek-threatening Patent Message-ID: <20050107153018.660433D81@xprdmailfe10.nwk.excite.com> Skipped content of type multipart/alternative-------------- next part -------------- _______________________________________________ vanilla-clients mailing list vanilla-clients@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-clients From bogus@does.not.exist.com Wed Jan 12 00:50:03 2005 From: bogus@does.not.exist.com () Date: Wed Jan 12 00:50:27 2005 Subject: No subject Message-ID: http://sourceforge.net/projects/netrek I didn't place it on any ftp servers yet. Kurt (007) -- Kurt Siegl / Franzberg 4, A-4483 Hargelsberg, Austria Email: Kurt.Siegl@freemail.at Tel (ISDN): *(7225)7017 URL: http://members.aon.at/presents/siegl/kurt/ From neilson at usc.edu Wed Jan 12 00:50:03 2005 From: neilson at usc.edu (D. Alex Neilson) Date: Wed Jan 12 00:50:30 2005 Subject: [Netrek Clients] cow doc not found Message-ID: Hi, Got this when trying to get the cow doc package: Not Found The requested URL /cow/current/COW.3.00pl3.doc.tar.gz was not found on this server. I'm trying to find the instructions on how to play cambot files back, in particular how does one show planet resources rather than just ownership? It's in my .xtrekrc file, but not working. Thanks, Alex From listing21 at desertmail.com Wed Jan 12 00:50:03 2005 From: listing21 at desertmail.com (listing21@desertmail.com) Date: Wed Jan 12 00:50:39 2005 Subject: [Netrek Clients] ADV: Search Engine Placement Message-ID: <003a23a66b6e$8324b2e8$3eb65ac6@ulybtd> To remove see below. I work with a company that submits web sites to search engines and saw your listing on the internet. We can submit your site twice a month to over 400 search engines and directories for only $29.95 per month. We periodically mail you progress reports showing where you are ranked. To get your web site in the fast lane call our toll free number below! Sincerely, Mike Bender 888-892-7537 * All work is verified To be removed call: 888-800-6339 X1377 From register08 at desertmail.com Wed Jan 12 00:50:03 2005 From: register08 at desertmail.com (register08@desertmail.com) Date: Wed Jan 12 00:50:40 2005 Subject: [Netrek Clients] ADV: Search Engine Registration Message-ID: <002b65e05d0e$2285b8b2$3bc54ba7@jpfyku> To remove see below. I work with a company that submits web sites to search engines and saw your listing on the internet. We can submit your site twice a month to over 400 search engines and directories for only $29.95 per month. We periodically mail you progress reports showing where you are ranked. To get your web site in the fast lane call our toll free number below! Sincerely, Mike Bender 888-892-7537 * All work is verified To be removed call: 888-800-6339 X1377 From bogus@does.not.exist.com Wed Jan 12 00:50:03 2005 From: bogus@does.not.exist.com () Date: Wed Jan 12 00:50:41 2005 Subject: No subject Message-ID: What the heck is this spike directory? I started to use Extreme Programming (XP) on my last development project and was really impressed with it. It impressed me so much, I mandated it for all development projects at Real Time. In getting cow to use SDL sound (SDL_mixer) I used XP principles, a Spike Solution is one such principle. You create a spike solution to reduce risk . Since I have never done any programming for sound, SDL, SDL_mixer, and cow itself. Ripping out the existing sound system was pretty risky (to me). So I created a spike solution to learn about SDL, cow, sound, and how it all could work together. As I move forward I'll be adding more to the spike area. My first spike solution was sdlwave. I just wanted to see some code and write some code to play some sort of sound on RedHat Intel 6.2/7.2/7.3 with GNOME You create a spike solution to reduce risk . Since I have never done any programming for sound, SDL, SDL_mixer, and cow itself. Ripping out the existing sound system was pretty risky (to me). So I created a spike solution to learn about SDL, cow, sound, and how it all could work together. As I move forward I'll be adding more to the spike area. My first spike solution was sdlwave. I just wanted to see some code and write some code to play some sort of sound on RedHat Intel 6.2/7.2/7.3 with GNOME or KDE. My second spike solution was cow-test. I wanted to see how SDL_mixer would play the cow sounds. The cow-test spike is the code that non-redhat users should compile and test to see if it works. See each sub-directory's README for details about that particular spike solution. -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org, Minnesota, Linux | Fax : (952)943-8500 http://www.tcwug.org, Minnesota, Wireless | Coding isn't a crime. Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From vanillatrek at yahoo.com Tue Jan 4 02:37:55 2005 From: vanillatrek at yahoo.com (Zach) Date: Wed Jan 12 00:51:07 2005 Subject: [Vanilla Devel] cvs server access, hardware problems, security issues In-Reply-To: <200410231749.56895@www.mn-linux.org.or.transmuter.real-time.com> Message-ID: <20050104083755.61288.qmail@web21122.mail.yahoo.com> Hi Bob, If the CVS pserver for Vanilla is back up could you please tell me the correct username, password and path to install Vanilla on my box. Thanks! Zach --- Bob Tanner wrote: > This post is way overdue. I apologize. > > Back in Aug(!) we had some hardware problems with the cvs > server. See > > http://archives.real-time.com/pipermail/vanilla-devel/2004-August/000599.html > > I had to delegate replacing the RAM to someone, which > took some time. This is > all old news. > > After replacing the RAM, the hard drive started to throw > CRC errors, so there > was additional down time to get a new drive into the box > and the data > migrated over. > > This was followed probes against the cvs server looking > for CAN-2004-0396. See > > http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0396 > > This was middle of Sep, since I was offsite, I just > applied a draconian ACL > (quick fix) to block pserver access to cvs until I had > more time to look into > the problem. > > I am off-contract now and have the time to re-address > this issue. I > re-apologize for the down time and the slowness on > getting things back > online. > > Because vanilla shares cvs access with other projects, it > will take a bit of > time to upgrade cvs to a secure version, as I will need > to coordinate with > the other cvs-librarians to make sure the upgrade doesn't > break anything. > > I'll post here when things are ready for testing. > > As an aside, I'll also be posting on cvs usage in > vanilla/netrek development, > the problems with cvs, and potential solutions. > > -- > Bob Tanner > Key fingerprint = AB15 0BDF BCDE 4369 5B42 1973 7CF1 > A709 2CC1 B288 > > ATTACHMENT part 1.2 application/pgp-signature > _______________________________________________ > vanilla-devel mailing list > vanilla-devel@us.netrek.org > https://mailman.real-time.com/mailman/listinfo/vanilla-devel > __________________________________ Do you Yahoo!? Send a seasonal email greeting and help others. Do good. http://celebrity.mail.yahoo.com _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From vanillatrek at yahoo.com Tue Jan 4 02:55:46 2005 From: vanillatrek at yahoo.com (Zach) Date: Wed Jan 12 00:51:07 2005 Subject: [Vanilla Devel] My complaints regarding cvs and proposed solution In-Reply-To: <200410231832.11770@www.mn-linux.org.or.transmuter.real-time.com> Message-ID: <20050104085546.24154.qmail@web21127.mail.yahoo.com> Is BitKeeper (bk) a client for Gnu Arch? I read about another program that is gaining ground on CVS. Forget the name! Zach --- Bob Tanner wrote: > In a previous post I mentioned the "future of cvs" as a > tool of development in > the vanilla/netrek project. > > I have really become disenchanted with cvs. 4 reasons > why this has happened. > > 1. My last contract introduced me to BitKeeper (bk) and > all the hype on lkml > about how wonderful this tool can be, is all true. Using > bk shows all the > problems with cvs. > > 2. Another FOSS project I contribute had our main cvs > server compromised. > Given that this project runs as root(!) it's ideal > candidate for being Trojan > horsed. We spent months(!) integrity checking the source > files. Wasted time! > This is because cvs doesn't have any sort of repository > integrity check. > > 3. While doing the software inventory, it was discovered > that cvs commits we > applied to the repository as a legitimate writer > (developer with write > access), only to find out that this person, had -not- > committed the code. The > commits where by an imposter, who was using this > developers "identity". This > is because cvs doesn't have any sort of commit > integrity/identity check. > > 4. cvs central development model, is adequate, but it is > elitist. Potential > developers must ask (beg?) to have write access to the > repository. My > example here is on another FOSS project I started writing > unit tests. I have > hundreds of tests now and still no commit access. So, I > end up making diffs, > putting them into SF's patch manager (time consuming!) > and wait for upstream > developers to merge those patches back into cvs (time > consuming!) only to > have certain diffs rejected because upstream code changed > between the time I > made the diff and the time the diffs where applied to > upstream cvs. I could > rant here more, but you get the picture. > > Now my proposed solution; migrate from cvs to GNU arch. > > #1. While I love bk, it's license is not FOSS friendly > (imho) and it won't sit > well with many people to require it as development tool. > But a very close > equivalent to it is GNU arch. Which is FOSS and works > great. > > These are the recommended "Executive Summaries" you > should look at: > > What is Arch? > http://wiki.gnuarch.org/moin.cgi/What_20is_20Arch_3f > > Why Arch? > http://wiki.gnuarch.org/moin.cgi/WhyArch > > The comparison sections are good as well. > > #2. GNU arch allows for gnupg signed archives. So we have > a crypto-signed > archive of files which would make integrity checking > (after a compromise) > much easier. > > Signing Archives > http://wiki.gnuarch.org/moin.cgi/Signing_20Archives > > #3. GNU arch allows for gnupg signed changesets (cvs > commits). We get both > authorization/authentication with gnupg signed > changesets. As a side effect, > we get the ability to track every changeset to a > developer via their gnupg > key. > > Signed changeset > http://wiki.gnuarch.org/moin.cgi/Signing_20Archives#head-53c693c1951e2566cd4c58547848c077ff24ae41 > > #4. GNU arch is totally distributed. There is no need to > beg for commit > access, since everyone can have their own private > archive. GNU arch makes it > very easy to merge changes from one archive into your own > archive. > > This is not to say, we cannot have a central development > model. > > Centralized Development > http://wiki.gnuarch.org/moin.cgi/Centralized_20Development > > Versioning strategies > http://wiki.gnuarch.org/moin.cgi/Versioning_20strategies > > But it does allow for distribution of the source code so > we don't have a > single point of failure, like we do now with > cvs.us.netrek.org > > We do not have to stop cvs cold-turkey. We can migrate > slowly(?) if we have > to. > > Interoperating with CVS > http://wiki.gnuarch.org/moin.cgi/Interoperating_20with_20CVS > > Tracking a project that doesn't use Arch > http://wiki.gnuarch.org/moin.cgi/Tracking_20a_20project_20that_20doesn_27t_20use_20Arch > > What does everyone think? > > -- > Bob Tanner > Key fingerprint = AB15 0BDF BCDE 4369 5B42 1973 7CF1 > A709 2CC1 B288 > > ATTACHMENT part 1.2 application/pgp-signature > _______________________________________________ > vanilla-devel mailing list > vanilla-devel@us.netrek.org > https://mailman.real-time.com/mailman/listinfo/vanilla-devel > __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From vanillatrek at yahoo.com Tue Jan 4 04:11:04 2005 From: vanillatrek at yahoo.com (Zach) Date: Wed Jan 12 00:51:07 2005 Subject: [Vanilla Devel] address format? Message-ID: <20050104101104.61889.qmail@web21126.mail.yahoo.com> What is the canonical way to send mail to this list? The website says to use: vanilla-devel@archives.real-time.com yet the mail I receive says: vanilla-devel@us.netrek.org Zach __________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From vanillatrek at yahoo.com Tue Jan 4 04:25:04 2005 From: vanillatrek at yahoo.com (Zach) Date: Wed Jan 12 00:51:08 2005 Subject: [Vanilla Devel] INL servers all down ! Clue servers? Message-ID: <20050104102504.35646.qmail@web21127.mail.yahoo.com> It seems there are no servers running INL mode anymore :( Chiko called a clue game the other week and we couldn't find any servers with INL (or WNL) running. Here are the results of my survey: netrek.crackaddict.com - machine down twink.crackaddict.com - machine down pickled.fox.cs.cmu.edu - machine down inl.real-time.com - INL mode disabled genocide.netrek.org - INL mode disabled ileocecal.vec.wfubmc.edu - INL mode disabled leaf.lumiere.net - INL mode disabled mojo.berkeley.edu - INL mode disabled orion.netrek.org - INL mode disabled neural.psychosis.net - INL mode disabled continuum.us.netrek.org - INL mode disabled eurotwinks.netrek.org - INL mode disabled pickled.psychosis.net - INL mode disabled netrek.gctc.hwy.com.au - machine down BTW the hockey clue mode seems to not be working on puck.tamu.edu Regards, Zach (Yoda) __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From vanillatrek at yahoo.com Tue Jan 4 04:34:52 2005 From: vanillatrek at yahoo.com (Zach) Date: Wed Jan 12 00:51:08 2005 Subject: [Vanilla Devel] Compiling Vanilla with INL mode? Message-ID: <20050104103452.64822.qmail@web21126.mail.yahoo.com> Hello, When I compile Vanilla ./configure tells me that no gmp.h was found yet I clearly have the GMP package installed! How do I get a Vanilla server with INL mode compiled and running? This will only be used for local testing purposes. Zach __________________________________ Do you Yahoo!? Yahoo! Mail - 250MB free storage. Do more. Manage less. http://info.mail.yahoo.com/mail_250 _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From vanillatrek at yahoo.com Tue Jan 4 04:33:04 2005 From: vanillatrek at yahoo.com (Zach) Date: Wed Jan 12 00:51:08 2005 Subject: [Vanilla Devel] lists? Message-ID: <20050104103304.64684.qmail@web21126.mail.yahoo.com> Hello, How do I see what lists I am subscribed to? I tried lists.real-time.com but it only showed the lists available and had a login for list admin only. IIRC i'm subscribed to vanilla-devel, vanilla-list, vanilla-clue-pickup and rec.games.netrek yet my recent message only seems to have showed up on vanilla-devel. Zach __________________________________ Do you Yahoo!? The all-new My Yahoo! - What will yours do? http://my.yahoo.com _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From vanillatrek at yahoo.com Tue Jan 4 04:42:14 2005 From: vanillatrek at yahoo.com (Zach) Date: Wed Jan 12 00:51:08 2005 Subject: [Vanilla Devel] Clients not blessed Message-ID: <20050104104214.65651.qmail@web21126.mail.yahoo.com> Hello, I can't seem to find any BRMH 2.4 or Paradise RC3 binaries that are blessed for pickled.psychosis.net I downloaded the binaries from ftp.netrek.org The BRMH 2.4 binaries either ghostbust write away or complain about not finding mpz_init() :( The Paradise RC3 client just says that "This is not a blessed client." So far the ONLY linux client I've found that works on pickled is the Paradise 2.99 FINAL client ! Heeeeeelp! I've not the only one with this problem. Recently Nimret was having same issues with BRMH 2.4 as well. I'd gladly do a fresh compile if someone will put them up on ftp.netrek.org I've mailed Karth several times but have received no replies in the past several months regarding this issue. Regards, Zach __________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From vanillatrek at yahoo.com Tue Jan 4 05:09:10 2005 From: vanillatrek at yahoo.com (Zach) Date: Wed Jan 12 00:51:08 2005 Subject: [Vanilla Devel] CVS update: Vanilla/gum In-Reply-To: <200402140528.i1E5SEb04662@swashbuckler.real-time.com> Message-ID: <20050104110910.46716.qmail@web21123.mail.yahoo.com> What is this Admin GUI and how do I get it working? Zach --- Vanilla CVS Development wrote: > 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) __________________________________ Do you Yahoo!? Send holiday email and support a worthy cause. Do good. http://celebrity.mail.yahoo.com _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From David.Watson at team17.com Tue Jan 4 07:06:06 2005 From: David.Watson at team17.com (David Watson) Date: Wed Jan 12 00:51:08 2005 Subject: [Vanilla Devel] INL servers all down ! Clue servers? In-Reply-To: <20050104102504.35646.qmail@web21127.mail.yahoo.com> Message-ID: <5.2.0.9.0.20050104130551.05b34fa0@mailgate.team17.com> I considered eurotwinks to be only of interest to the ET team when playing so I did not start an INL server up again after a disk crash... I have a pl7 INL server online at that address with standard ports, I'm not sure if there is any access to the latest server code at the moment. If there are problems with this server let me know. At 03:35 04/01/2005 -0800, you wrote: >It seems there are no servers running INL mode anymore :( > >Chiko called a clue game the other week and we couldn't >find any servers with INL (or WNL) running. > >Here are the results of my survey: > >netrek.crackaddict.com - machine down >twink.crackaddict.com - machine down >pickled.fox.cs.cmu.edu - machine down >inl.real-time.com - INL mode disabled >genocide.netrek.org - INL mode disabled >ileocecal.vec.wfubmc.edu - INL mode disabled >leaf.lumiere.net - INL mode disabled >mojo.berkeley.edu - INL mode disabled >orion.netrek.org - INL mode disabled >neural.psychosis.net - INL mode disabled >continuum.us.netrek.org - INL mode disabled >eurotwinks.netrek.org - INL mode disabled >pickled.psychosis.net - INL mode disabled >netrek.gctc.hwy.com.au - machine down > > >Regards, >Zach (Yoda) > > > >__________________________________ >Do you Yahoo!? >Take Yahoo! Mail with you! Get it on your mobile phone. >http://mobile.yahoo.com/maildemo > >_______________________________________________ >vanilla-clue-pickup mailing list >vanilla-clue-pickup@us.netrek.org >https://mailman.real-time.com/mailman/listinfo/vanilla-clue-pickup _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From msucka0xff at programmer.net Tue Jan 4 16:30:00 2005 From: msucka0xff at programmer.net (. .) Date: Wed Jan 12 00:51:08 2005 Subject: [Vanilla Devel] Clients not blessed Message-ID: <20050104223000.62FBB1F50B1@ws1-2.us4.outblaze.com> >The BRMH 2.4 binaries either ghostbust write away or >complain about not finding mpz_init() :( Zach, You prolly need libgmp. Apt get gmp for debian. See if you don't already have that package installed. If not, I would suspect that the RSA key is OK, but that the lack of gmp code causes the large integer operations to fail. ldd your client to see how it is resolving its symbols. Check to see libgmp.so or libgmp.a exists, along with the other libs. -bd -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From msucka0xff at programmer.net Tue Jan 4 16:32:06 2005 From: msucka0xff at programmer.net (. .) Date: Wed Jan 12 00:51:08 2005 Subject: [Vanilla Devel] lists? Message-ID: <20050104223206.E7FAC1F50B1@ws1-2.us4.outblaze.com> try https://mailman.real-time.com/mailman/listinfo/ -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From quozl at us.netrek.org Tue Jan 4 18:00:27 2005 From: quozl at us.netrek.org (James Cameron) Date: Wed Jan 12 00:51:08 2005 Subject: [Vanilla Devel] INL servers all down ! Clue servers? In-Reply-To: <20050104102504.35646.qmail@web21127.mail.yahoo.com> References: <20050104102504.35646.qmail@web21127.mail.yahoo.com> Message-ID: <20050105000027.GB14402@us.netrek.org> On Tue, Jan 04, 2005 at 02:25:04AM -0800, Zach wrote: > netrek.gctc.hwy.com.au - machine down Host name incorrect. It is netrek.hwy.com.au, and I was able to connect a client fine. INL mode is probably disabled though. -- 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 msucka0xff at programmer.net Wed Jan 5 09:20:02 2005 From: msucka0xff at programmer.net (. .) Date: Wed Jan 12 00:51:08 2005 Subject: [Vanilla Devel] Re: [Netrek Clients] Clients not blessed Message-ID: <20050105152003.8D20C6F027@ws1-5.us4.outblaze.com> ----- Original Message ----- From: Zach > I can't seem to find any BRMH 2.4 or Paradise RC3 > binaries that are blessed for pickled.psychosis.net > > The BRMH 2.4 binaries either ghostbust write away or > complain about not finding mpz_init() :( mpz_init symbol has changed to gmpz_init, u may need to recompile your libgmp (unless recompile the src with the key). I feel confident saying that the RSA key is more than likely good even though I don't know which one it uses. Try checking the command line options to see if it prints this info out, then check to see if it's on the metaserver's list. -bd p.s. try a statically linked version -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm _______________________________________________ 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 Jan 5 21:54:58 2005 From: quozl at us.netrek.org (James Cameron) Date: Wed Jan 12 00:51:08 2005 Subject: [Vanilla Devel] CVS update: Vanilla/gum In-Reply-To: <20050104110910.46716.qmail@web21123.mail.yahoo.com> References: <200402140528.i1E5SEb04662@swashbuckler.real-time.com> <20050104110910.46716.qmail@web21123.mail.yahoo.com> Message-ID: <20050106035458.GA374@us.netrek.org> On Tue, Jan 04, 2005 at 03:09:10AM -0800, Zach wrote: > What is this Admin GUI and how do I get it working? % cd gum % ./configure % make % make install http://quozl.linux.org.au/gum/shots/ for very old pictures. -- 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 Thu Jan 6 07:51:56 2005 From: Shadow.Hunter at netrek.org (E. Hietbrink) Date: Wed Jan 12 00:51:08 2005 Subject: [Vanilla Devel] Re: Need Help Busting Netrek-threatening Patent Message-ID: <41DD427C.1020606@netrek.org> FYI, I received a request to bust some patent with prior art: Netrek.I remember things like this popping up before in the past. Who handled it back then and what was it about? Anyway, find below a quick draft of my answer to Nick Schuneman. Can you guys go over it and correct/extend where appropriate? I do not know all the answers. Let's try to give him a prompt response. I do not want to ask the guy this now, but I'd like to know how we can *prove* that the features we discuss were present in Netrek/Xtrek in the 80's? Anyone still has CVS logfiles? Or what methods could we use for that? Further: is it normal to not disclose further details of the conflicting patent? Regards, Erik > Date: Wed, 5 Jan 2005 15:57:36 -0500 > From: nschunem@law.harvard.edu > To: Shadow.Hunter@netrek.org > Subject: Need Help Busting Netrek-threatening Patent > > Hello, > > My name is Nick Schuneman. I am a second year law student at Harvard, and am > working this winter on a project to "bust" (i.e. invalidate) > technology-constricting patents. A noble cause indeed! > One of the patents we are trying to > invalidate seemingly covers games like Netrek, and if upheld as valid by the > Patent Office, could be used to enjoin Netrek players from enjoying their > favorite pastime and even sue Netrek users and developers for monetary damages. > In fact, the patent owner has already shown a propensity for threatening > small-time and non-profit operations that he feels infringe his patent. It it possible for you to disclose more information about the patent in question? Out of curiosity (obviously I am not a lawyer), but Netrek has always been open source and never required any fees to play, and never pushed other competing games out of the market, so how could anyone sue for monetary damages in that case? > However, there is some good news. Netrek was developed prior to the critical > date of the patent (which dates back to 1996), and therefore may help to bust > the patent and protect the innovative activities of those in the on-line gaming > community. I have read the Netrek FAQ and Newbie guide, and have compiled a > good deal of information that will be helpful in busting the patent at issue. > But I still have a few blanks that I hope you could help fill in (or at least > point me in the right direction). Any information you an provide would be of > great help in our effort to prevent bullying of community-minded software > developers. Netrek in its current form was born in 1988, so that should adequately predate this patent. But many of the game features that you inquire are even present in Netrek's direct predecessors, Xtrek, Conquest and Empire, dating back to the early 80's. > Please bear in mind that I'm not a gamer, so I apologize if I use any > inappropriate or absurd vocabulary to describe certain features of the game. > > (1) How often are the ratings / rankings updated? Question to you all: is this per server tick? =10 times per second? > (2) Are the rankings of other players transmitted (and displayed) to each player > during the game play? Yes, both transmitted and displayed during game play. Outside the game the statistics overview can be generated at arbitrary intervals. > (3) Can players log on / log off of a game while other players continue to > play? Yes. There is no requirement for all players to be present before a game can start. They can come and go as they please. A minimum of 4 players on 2 teams is required however to start "Tournament mode" which is the game phase where statistics and rankings are updated. > (4) I read in the FAQ that rankings are only compiled in the "tournament mode." > Is it possible for players to log on and off during the tournament mode game > while other players continue to play? See my answer to (3). At all times it is possible for players to join and leave the game. The latter can also happen unintentionally when a network connection between the server and the player is broken. The game server detects this and cleans up the "slot" for a new player. At most the game server allows 16 concurrent players. When there are more interested players, they will be put into a waiting queue from which they can join the game as soon as a slot opens. > Thank you so much for your help! If you are interested in any further > information regarding the patent-busting project, there is a nice explanation > on the Electronic Frontier Foundation's website: > > http://www.eff.org/patent/wanted/patent.php?p=sheldon > > Thank you, > > Nick Schuneman > > Clinical Student > Berkman Center for Internet & Society > Harvard Law School > nschunem@law.harvard.edu _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From jrd at gerdesas.com Thu Jan 6 09:29:11 2005 From: jrd at gerdesas.com (jrd@gerdesas.com) Date: Wed Jan 12 00:51:08 2005 Subject: [Vanilla Devel] Re: Need Help Busting Netrek-threatening Patent In-Reply-To: <41DD427C.1020606@netrek.org> from "E. Hietbrink" at Jan 06, 2005 02:51:56 PM Message-ID: <20050106152911.13322.qmail@gerdesas.gerdesas.com> In previous mail, E. Hietbrink spouted... > > Netrek in its current form was born in 1988, so that should adequately predate > this patent. But many of the game features that you inquire are even present > in Netrek's direct predecessors, Xtrek, Conquest and Empire, dating back to the > early 80's. I am looking at title page of the original version of 'empire' at the moment, the game that all these derive from. "Copyright 1977, 78, 83 -- by Charles Miller and Gary Fritz" I can get you contact information for Miller if you'd like - I have no idea with Fritz has been for the past 20+ years, tho. This is not being sent to Nick - if you want to forward it on, please feel free. John -- "I'm sorry but our engineers do not have phones." As stated by a Network Solutions Customer Service representative when asked to put me through to an engineer. "My other computer is your windows box." Ralf Hildebrandt _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From ahn at orion.netrek.org Thu Jan 6 10:44:32 2005 From: ahn at orion.netrek.org (Dave Ahn) Date: Wed Jan 12 00:51:08 2005 Subject: [Vanilla Devel] Re: Need Help Busting Netrek-threatening Patent In-Reply-To: <41DD427C.1020606@netrek.org> References: <41DD427C.1020606@netrek.org> Message-ID: <20050106164432.GA23511@orion.netrek.org> The previous case was Lipstream vs HearMe. This IP law suit was settled due to prior art in Netrek. Unfortunately the patent itself was not overturned. A number of key netrek contributors were involved in this law suit including myself. I have a copy of the motion for summary judgment at www.netrek.org/archive/patent/SJ_Motion.pdf which is available to the netrek community as a result of our help. I do not know if the settlement itself was sealed. If you search vanilla-list, there should be some archived messages about this issue. Dave On Thu, Jan 06, 2005 at 02:51:56PM +0100, E. Hietbrink wrote: > FYI, I received a request to bust some patent with prior art: Netrek.I > remember > things like this popping up before in the past. Who handled it back then and > what was it about? > > Anyway, find below a quick draft of my answer to Nick Schuneman. Can you > guys > go over it and correct/extend where appropriate? I do not know all the > answers. > Let's try to give him a prompt response. > > I do not want to ask the guy this now, but I'd like to know how we can > *prove* > that the features we discuss were present in Netrek/Xtrek in the 80's? > Anyone > still has CVS logfiles? Or what methods could we use for that? > > Further: is it normal to not disclose further details of the conflicting > patent? > > Regards, > Erik > > > > > >Date: Wed, 5 Jan 2005 15:57:36 -0500 > >From: nschunem@law.harvard.edu > >To: Shadow.Hunter@netrek.org > >Subject: Need Help Busting Netrek-threatening Patent > > > >Hello, > > > >My name is Nick Schuneman. I am a second year law student at Harvard, and > >am > >working this winter on a project to "bust" (i.e. invalidate) > >technology-constricting patents. > > A noble cause indeed! > > > >One of the patents we are trying to > >invalidate seemingly covers games like Netrek, and if upheld as valid by > >the > >Patent Office, could be used to enjoin Netrek players from enjoying their > >favorite pastime and even sue Netrek users and developers for monetary > >damages. > > In fact, the patent owner has already shown a propensity for threatening > >small-time and non-profit operations that he feels infringe his patent. > > It it possible for you to disclose more information about the patent in > question? > Out of curiosity (obviously I am not a lawyer), but Netrek has always been > open > source and never required any fees to play, and never pushed other competing > games out of the market, so how could anyone sue for monetary damages in > that > case? > > > >However, there is some good news. Netrek was developed prior to the > >critical > >date of the patent (which dates back to 1996), and therefore may help to > >bust > >the patent and protect the innovative activities of those in the on-line > >gaming > >community. I have read the Netrek FAQ and Newbie guide, and have compiled > >a > >good deal of information that will be helpful in busting the patent at > >issue. But I still have a few blanks that I hope you could help fill in > >(or at least > >point me in the right direction). Any information you an provide would be > >of > >great help in our effort to prevent bullying of community-minded software > >developers. > > Netrek in its current form was born in 1988, so that should adequately > predate > this patent. But many of the game features that you inquire are even present > in Netrek's direct predecessors, Xtrek, Conquest and Empire, dating back to > the > early 80's. > > > >Please bear in mind that I'm not a gamer, so I apologize if I use any > >inappropriate or absurd vocabulary to describe certain features of the > >game. > > > >(1) How often are the ratings / rankings updated? > > Question to you all: is this per server tick? =10 times per second? > > > >(2) Are the rankings of other players transmitted (and displayed) to each > >player > >during the game play? > > Yes, both transmitted and displayed during game play. Outside the game the > statistics overview can be generated at arbitrary intervals. > > > >(3) Can players log on / log off of a game while other players continue to > >play? > > Yes. There is no requirement for all players to be present before a game can > start. They can come and go as they please. A minimum of 4 players on 2 > teams > is required however to start "Tournament mode" which is the game phase where > statistics and rankings are updated. > > > >(4) I read in the FAQ that rankings are only compiled in the "tournament > >mode." Is it possible for players to log on and off during the tournament > >mode game > >while other players continue to play? > > See my answer to (3). At all times it is possible for players to join and > leave > the game. The latter can also happen unintentionally when a network > connection > between the server and the player is broken. The game server detects this > and > cleans up the "slot" for a new player. At most the game server allows 16 > concurrent players. When there are more interested players, they will be put > into a waiting queue from which they can join the game as soon as a slot > opens. > > > >Thank you so much for your help! If you are interested in any further > >information regarding the patent-busting project, there is a nice > >explanation > >on the Electronic Frontier Foundation's website: > > > >http://www.eff.org/patent/wanted/patent.php?p=sheldon > > > >Thank you, > > > >Nick Schuneman > > > >Clinical Student > >Berkman Center for Internet & Society > >Harvard Law School > >nschunem@law.harvard.edu > > > > > _______________________________________________ > 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 tanner at real-time.com Thu Jan 6 11:21:12 2005 From: tanner at real-time.com (Bob Tanner) Date: Wed Jan 12 00:51:08 2005 Subject: [Vanilla Devel] My complaints regarding cvs and proposed solution In-Reply-To: <20050104085546.24154.qmail@web21127.mail.yahoo.com> References: <20050104085546.24154.qmail@web21127.mail.yahoo.com> Message-ID: <200501061121.12507@www.mn-linux.org.or.transmuter.real-time.com> On Tuesday 04 January 2005 02:55 am, Zach wrote: > Is BitKeeper (bk) a client for Gnu Arch? No. http://www.gnu.org/software/gnu-arch/ http://wiki.gnuarch.org/ In particular http://better-scm.berlios.de/comparison/ -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org, Minnesota, Linux | Fax : (952)943-8500 Key fingerprint = AB15 0BDF BCDE 4369 5B42 1973 7CF1 A709 2CC1 B288 _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From tanner at real-time.com Thu Jan 6 11:19:20 2005 From: tanner at real-time.com (Bob Tanner) Date: Wed Jan 12 00:51:09 2005 Subject: [Vanilla Devel] cvs server access, hardware problems, security issues In-Reply-To: <20050104083755.61288.qmail@web21122.mail.yahoo.com> References: <20050104083755.61288.qmail@web21122.mail.yahoo.com> Message-ID: <200501061119.20667@www.mn-linux.org.or.transmuter.real-time.com> On Tuesday 04 January 2005 02:37 am, Zach wrote: > If the CVS pserver for Vanilla is back up could you please > tell me the correct username, password and path to install > Vanilla on my box. Thanks! cvs pserver access won't be coming back, unless Dave wants to host it on orion. -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org, Minnesota, Linux | Fax : (952)943-8500 Key fingerprint = AB15 0BDF BCDE 4369 5B42 1973 7CF1 A709 2CC1 B288 _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From 007 at freemail.at Thu Jan 6 11:21:04 2005 From: 007 at freemail.at (Kurt Siegl) Date: Wed Jan 12 00:51:09 2005 Subject: [Vanilla Devel] Re: [Netrek Clients] Re: Need Help Busting Netrek-threatening Patent In-Reply-To: <41DD427C.1020606@netrek.org> References: <41DD427C.1020606@netrek.org> Message-ID: <200501061821.05385.007@freemail.at> On Thursday 06 January 2005 14:51, E. Hietbrink wrote: > I do not want to ask the guy this now, but I'd like to know how we can > *prove* that the features we discuss were present in Netrek/Xtrek in the > 80's? Anyone still has CVS logfiles? Or what methods could we use for that? What I found quickly is an old CD of mine when I left university, which contains as oldest source distribution the calvin-2.2pl3.tar.gz Server and BRM.3.00pl3.tar.gz Client both with all the timestamps from 1993 which is enough for that purpose. I might try to get the bronco sources from somewhere or maybe Tom will find some archive with berkely server code. But anyway, I think the bronco code is the oldest modern Netrek server available. But wait, I just found the oldest RSA server code. Probably bronco code. rsa.netrek.tar.Z The archive has been created on 1993-01-18 :-) Kurt -- Kurt Siegl / Franzberg 4, A-4483 Hargelsberg, Austria Email: Kurt.Siegl@hargelsberg.at Tel (ISDN): *(7225)7017 URL: http://www.hargelsberg.at/siegl/kurt/ _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From ahn at orion.netrek.org Thu Jan 6 12:10:06 2005 From: ahn at orion.netrek.org (Dave Ahn) Date: Wed Jan 12 00:51:09 2005 Subject: [Vanilla Devel] Re: [Netrek Clients] Re: Need Help Busting Netrek-threatening Patent In-Reply-To: <200501061821.05385.007@freemail.at> References: <41DD427C.1020606@netrek.org> <200501061821.05385.007@freemail.at> Message-ID: <20050106181006.GA23965@orion.netrek.org> On Thu, Jan 06, 2005 at 06:21:04PM +0100, Kurt Siegl wrote: > On Thursday 06 January 2005 14:51, E. Hietbrink wrote: > > I do not want to ask the guy this now, but I'd like to know how we can > > *prove* that the features we discuss were present in Netrek/Xtrek in the > > 80's? Anyone still has CVS logfiles? Or what methods could we use for that? > > What I found quickly is an old CD of mine when I left university, which > contains as oldest source distribution the The timestamps from CD's don't matter much because Netrek was so widely distributed from early on. There are court documents that include signed declarations that Netrek dates back to the 80's, and a google search shows 136,000 results from numerous independent web sites with time stamps. The question of "when" cannot be refuted, so the only thing that remains is the question of relevance. That is, does Netrek implement ideas that are substantially similar to the patent claims so as to invalidate those claims based on prior art. I didn't look at the 879 patent, so I couldn't say. _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From ahn at orion.netrek.org Thu Jan 6 12:22:06 2005 From: ahn at orion.netrek.org (Dave Ahn) Date: Wed Jan 12 00:51:09 2005 Subject: [Vanilla Devel] cvs server access, hardware problems, security issues In-Reply-To: <200501061119.20667@www.mn-linux.org.or.transmuter.real-time.com> References: <20050104083755.61288.qmail@web21122.mail.yahoo.com> <200501061119.20667@www.mn-linux.org.or.transmuter.real-time.com> Message-ID: <20050106182206.GA24081@orion.netrek.org> On Thu, Jan 06, 2005 at 11:19:20AM -0600, Bob Tanner wrote: > > cvs pserver access won't be coming back, unless Dave wants to host it on > orion. I'm confused as to what's going on with CVS. Are you keeping CVS over SSH? Or moving to arch? Or SVN? If you're keeping CVS over SSH and are open to read-only rsync over SSH of the repository, I'd be happy to host a pserver mirror on orion. Dave _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From unbelver at us.netrek.org Thu Jan 6 15:48:02 2005 From: unbelver at us.netrek.org (Carlos Y. Villalpando) Date: Wed Jan 12 00:51:09 2005 Subject: [Vanilla Devel] Re: Need Help Busting Netrek-threatening Patent In-Reply-To: <20050106164432.GA23511@orion.netrek.org> References: <41DD427C.1020606@netrek.org> <20050106164432.GA23511@orion.netrek.org> Message-ID: <20050106214802.GA3051@brain.jpl.nasa.gov> Quoting Dave Ahn : > A number of key netrek contributors were involved in this law suit > including myself. Dave and I were interviewed by the defendant's IP attourneys vi e-mail and face to face during the Spring/Summer of 2000. We showed them what the game was, how it worked, and the technical background of the game and code overview. I was interviewed for about 4 hours or so at my home and I gave them an explanation of the game as it related to the Plaintiff's patent claims. The pdf Dave gave a link to does a good job describing what the patent claims were about and how Netrek related. After they were done with Dave and I, they were extremely excited, so we pointed them to the Netrek history Gurus and founders for the authoritative "Yes, this was going on before the patent was filed" statements, (Kevin Smith, et al.) They apparently got the declarations they needed from them. Afterwards, I was interviewed again for about 2 hours as a final loose end wrap-up. I got a nice dinner out of that one. We asked for, and received permission to do a Slashdot story along the lines of "Netrek helps kill a stupid patent", but I believe we decided not to when we heard the case was settled instead of having the patent invalidated. Since the patent was still in force, we thought it best to lay low since they could come after Netrek. > If you search vanilla-list, there should be some archived messages > about this issue. Dave, after the initial query by Chawla and the initial responses, you, James, and I decided to not tell the rest of the Netrek community what was going on after we found out who the interested parties were. So there's not much on the vanilla-l archive. Most of our discussions were via IRC, though we did have some e-mail interactions. For some odd reason, I didn't save my half of the emails, just you quoting me. --Carlos V. _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From ahn at orion.netrek.org Thu Jan 6 17:04:56 2005 From: ahn at orion.netrek.org (Dave Ahn) Date: Wed Jan 12 00:51:09 2005 Subject: [Vanilla Devel] Re: Need Help Busting Netrek-threatening Patent In-Reply-To: <20050106214802.GA3051@brain.jpl.nasa.gov> References: <41DD427C.1020606@netrek.org> <20050106164432.GA23511@orion.netrek.org> <20050106214802.GA3051@brain.jpl.nasa.gov> Message-ID: <20050106230456.GA25215@orion.netrek.org> On Thu, Jan 06, 2005 at 01:48:02PM -0800, Carlos Y. Villalpando wrote: > > Dave, after the initial query by Chawla and the initial responses, > you, James, and I decided to not tell the rest of the Netrek community > what was going on after we found out who the interested parties > were. So there's not much on the vanilla-l archive. I'm getting old and forgetful. I could have sworn I posted something to the lists. Anyway, I did get permission to publish the motion document to the community. It's a good read on how patent claims are contested. _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From vanillatrek at yahoo.com Fri Jan 7 06:26:54 2005 From: vanillatrek at yahoo.com (Zach) Date: Wed Jan 12 00:51:09 2005 Subject: [Vanilla Devel] cvs server access, hardware problems, security issues In-Reply-To: <200501061119.20667@www.mn-linux.org.or.transmuter.real-time.com> Message-ID: <20050107122654.90082.qmail@web21121.mail.yahoo.com> --- Bob Tanner wrote: > > cvs pserver access won't be coming back, unless Dave > wants to host it on > orion. gadzooks! so if i want to update 1 file in Vanilla I'll have to download/re-install the entire tarball? *cry* zach in dialup pain __________________________________ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250 _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From vanillatrek at yahoo.com Fri Jan 7 06:35:56 2005 From: vanillatrek at yahoo.com (Zach) Date: Wed Jan 12 00:51:09 2005 Subject: [Vanilla Devel] Re: Need Help Busting Netrek-threatening Patent In-Reply-To: <20050106214802.GA3051@brain.jpl.nasa.gov> Message-ID: <20050107123556.16151.qmail@web21122.mail.yahoo.com> --- "Carlos Y. Villalpando" wrote: > Quoting Dave Ahn : > > > A number of key netrek contributors were involved in > this law suit > > including myself. > > Dave and I were interviewed by the defendant's IP > attourneys vi e-mail > and face to face during the Spring/Summer of 2000. We > showed them > what the game was, how it worked, and the technical > background of the > game and code overview. I was interviewed for about 4 > hours or so at > my home and I gave them an explanation of the game as it > related to > the Plaintiff's patent claims. The pdf Dave gave a link > to does a > good job describing what the patent claims were about and > how Netrek > related. > > After they were done with Dave and I, they were extremely > excited, so > we pointed them to the Netrek history Gurus and founders > for the > authoritative "Yes, this was going on before the patent > was filed" > statements, (Kevin Smith, et al.) They apparently got > the > declarations they needed from them. > > Afterwards, I was interviewed again for about 2 hours as > a final loose > end wrap-up. I got a nice dinner out of that one. > > We asked for, and received permission to do a Slashdot > story along the > lines of "Netrek helps kill a stupid patent", but I > believe we decided > not to when we heard the case was settled instead of > having the patent > invalidated. Since the patent was still in force, we > thought it best > to lay low since they could come after Netrek. > > > If you search vanilla-list, there should be some > archived messages > > about this issue. > > Dave, after the initial query by Chawla and the initial > responses, > you, James, and I decided to not tell the rest of the > Netrek community > what was going on after we found out who the interested > parties > were. So there's not much on the vanilla-l archive. > > Most of our discussions were via IRC, though we did have > some e-mail > interactions. For some odd reason, I didn't save my half > of the > emails, just you quoting me. Very interesting! Perhaps it's best to let sleeping dogs lie? If this Harvard project launches another challenge to the patent could this not cause the patent holder to take legal action against netrek a la SCO's case against Linux kernel? Or if the worst case happened could we not nullify the patent by some minor code changes? Zach __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From kbernatz at excite.com Fri Jan 7 09:30:18 2005 From: kbernatz at excite.com (Kevin Bernatz) Date: Wed Jan 12 00:51:09 2005 Subject: [Vanilla Devel] Fwd: [Netrek Clients] Re: Need Help Busting Netrek-threatening Patent Message-ID: <20050107153018.660433D81@xprdmailfe10.nwk.excite.com> Skipped content of type multipart/alternative-------------- next part -------------- _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From bgrubin at pobox.com Sat Jan 8 05:05:48 2005 From: bgrubin at pobox.com (Benjamin P. Grubin) Date: Wed Jan 12 00:51:09 2005 Subject: [Vanilla Devel] Darwin client In-Reply-To: <20050105000027.GB14402@us.netrek.org> References: <20050104102504.35646.qmail@web21127.mail.yahoo.com> <20050105000027.GB14402@us.netrek.org> Message-ID: <41DFBE8C.3030801@pobox.com> Hey guys, I'm resending this here (previously sent to ftp.netrek.org maintainer with no response) since you guys seem to be active. Can someone with privs please copy the darwin COW binary I compiled nearly a year ago, that is still sitting in /incoming on the FTP server, to the appropriate spot so that it can be downloaded? Much appreciated, Ben _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From basic at us.netrek.org Tue Jan 11 15:20:03 2005 From: basic at us.netrek.org (Bob Tanner) Date: Wed Jan 12 00:51:09 2005 Subject: [Vanilla Devel] Migrate all vanilla-* email lists to netrek-* Message-ID: <200501111520.05743@www.mn-linux.org.or.transmuter.real-time.com> I think the below irc conversation sums up this posting: "netrek@us.netrek.org" for general discussions "netrek-dev@us.netrek.org" for development discussions "netrek-cvs@us.netrek.org" for CVS commit logs. I suggest toasting vanilla-announce, merging vanilla-clients into netrek-dev, vanilla-clue-pickup into netrek, vanilla-devel and vanilla-list into netrek-dev, vanilla-metaserver into netrek-dev. Expect to get several un-subscribe notifications and a couple subscribe notifications as I clean up the mailing lists. If you want details, please send me email off-list and I'll add you to the trouble ticket. -- Bob Tanner Key fingerprint = AB15 0BDF BCDE 4369 5B42 1973 7CF1 A709 2CC1 B288 _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From bogus@does.not.exist.com Wed Jan 12 00:50:03 2005 From: bogus@does.not.exist.com () Date: Wed Jan 12 00:51:35 2005 Subject: No subject Message-ID: - update t-mode messages, they are outdated. Explicit instructions - find where the t-mode messages are defined, - analyse each message for relevance to today's players, - perform age analysis of player base [optional], - prepare hot list of messages to be deleted, - prepare equal or greater list of messages to be added, - adjust the source code, - recompile the server, - test the messages appear correctly and fit in the windows, - submit the patch to the team for review, - submit the final patch to the team for insertion into CVS. -- James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/ From vanillatrek at yahoo.com Tue Jan 4 04:34:52 2005 From: vanillatrek at yahoo.com (Zach) Date: Wed Jan 12 00:51:55 2005 Subject: [Vanilla List] Compiling Vanilla with INL mode? Message-ID: <20050104103452.64822.qmail@web21126.mail.yahoo.com> Hello, When I compile Vanilla ./configure tells me that no gmp.h was found yet I clearly have the GMP package installed! How do I get a Vanilla server with INL mode compiled and running? This will only be used for local testing purposes. Zach __________________________________ Do you Yahoo!? Yahoo! Mail - 250MB free storage. Do more. Manage less. http://info.mail.yahoo.com/mail_250 _______________________________________________ vanilla-list mailing list vanilla-list@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-list From ahn at orion.netrek.org Tue Jan 4 16:46:19 2005 From: ahn at orion.netrek.org (Dave Ahn) Date: Wed Jan 12 00:51:55 2005 Subject: [Vanilla List] [bgrubin@pobox.com: ftp.netrek.org] Message-ID: <20050104224619.GA8105@orion.netrek.org> Is this a legitimate blessed client? Carlos? ----- Forwarded message from "Benjamin P. Grubin" ----- X-Gmail-Received: a303e6bf91df517c1bfb1a0ba7e3db27dd52b29a To: ahn@genocide.netrek.org From: Benjamin P.Grubin Subject: ftp.netrek.org X-pstn-levels: (S:99.90000/99.90000 R:95.9108 P:95.9108 M:97.0232 C:98.7678 ) X-pstn-settings: 5 (2.0000:2.0000) s gt3 gt2 gt1 r p m c X-pstn-addresses: from [407/23] Hey, The COW client for Mac OS X darwin I built in June is still sitting in incoming on ftp.netrek.org. Can you move it to the appropriate spot so people can download it? Thanks, Ben ----- End forwarded message ----- _______________________________________________ vanilla-list mailing list vanilla-list@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-list From ahn at orion.netrek.org Tue Jan 4 17:59:25 2005 From: ahn at orion.netrek.org (Dave Ahn) Date: Wed Jan 12 00:51:55 2005 Subject: [Vanilla List] mailing list changes Message-ID: <20050104235925.GA8595@orion.netrek.org> Hello, We are in the process of consolidating netrek mailing lists. You may notice that one or more mailing lists will stop working over the next few days. Please be patient in the interim, and an announcement will be sent out when the transition is complete. If you receive no message for at least a week, please check www.netrek.org or https://mailman.real-time.com/mailman/listinfo/ to check that you are still subscribed. Thanks. Dave _______________________________________________ vanilla-list mailing list vanilla-list@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-list From tanner at real-time.com Thu Jan 6 11:14:26 2005 From: tanner at real-time.com (Bob Tanner) Date: Wed Jan 12 00:51:55 2005 Subject: [Vanilla List] Compiling Vanilla with INL mode? In-Reply-To: <20050104103452.64822.qmail@web21126.mail.yahoo.com> References: <20050104103452.64822.qmail@web21126.mail.yahoo.com> Message-ID: <200501061114.27238@www.mn-linux.org.or.transmuter.real-time.com> On Tuesday 04 January 2005 04:34 am, Zach wrote: > How do I get a Vanilla server with INL mode compiled and > running? This will only be used for local testing purposes. Shaka, when the walls fell! What distro? What arch? -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org, Minnesota, Linux | Fax : (952)943-8500 Key fingerprint = AB15 0BDF BCDE 4369 5B42 1973 7CF1 A709 2CC1 B288 _______________________________________________ vanilla-list mailing list vanilla-list@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-list From tanner at real-time.com Thu Jan 6 11:15:57 2005 From: tanner at real-time.com (Bob Tanner) Date: Wed Jan 12 00:51:55 2005 Subject: [Vanilla List] mailing list changes In-Reply-To: <20050104235925.GA8595@orion.netrek.org> References: <20050104235925.GA8595@orion.netrek.org> Message-ID: <200501061115.57507@www.mn-linux.org.or.transmuter.real-time.com> On Tuesday 04 January 2005 05:59 pm, Dave Ahn wrote: > We are in the process of consolidating netrek mailing lists. ?You may > notice that one or more mailing lists will stop working over the next > few days. ?Please be patient in the interim, and an announcement will be > sent out when the transition is complete. ?If you receive no message for > at least a week, please check www.netrek.org or > https://mailman.real-time.com/mailman/listinfo/ to check that you are Feature creep! Will also be upgrading the mailing list server both hardware and OS. Will take a couple of days to complete the prep-work. -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org, Minnesota, Linux | Fax : (952)943-8500 Key fingerprint = AB15 0BDF BCDE 4369 5B42 1973 7CF1 A709 2CC1 B288 _______________________________________________ vanilla-list mailing list vanilla-list@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-list From quozl at us.netrek.org Fri Jan 7 01:14:34 2005 From: quozl at us.netrek.org (James Cameron) Date: Wed Jan 12 00:51:55 2005 Subject: [Vanilla List] Compiling Vanilla with INL mode? In-Reply-To: <20050104103452.64822.qmail@web21126.mail.yahoo.com> References: <20050104103452.64822.qmail@web21126.mail.yahoo.com> Message-ID: <20050107071434.GA6251@us.netrek.org> On Tue, Jan 04, 2005 at 02:34:52AM -0800, Zach wrote: > When I compile Vanilla ./configure tells me that no gmp.h > was found yet I clearly have the GMP package installed! You clearly don't have the GMP development package installed? e.g. if you have installed libgmp3, also install libgmp3-dev. > How do I get a Vanilla server with INL mode compiled and > running? This will only be used for local testing purposes. Follow the instructions in INSTALL.INL -- 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 From vanillatrek at yahoo.com Fri Jan 7 06:24:28 2005 From: vanillatrek at yahoo.com (Zach) Date: Wed Jan 12 00:51:55 2005 Subject: [Vanilla List] Compiling Vanilla with INL mode? In-Reply-To: <200501061114.27238@www.mn-linux.org.or.transmuter.real-time.com> Message-ID: <20050107122428.15050.qmail@web21122.mail.yahoo.com> --- Bob Tanner wrote: > On Tuesday 04 January 2005 04:34 am, Zach wrote: > > How do I get a Vanilla server with INL mode compiled > and > > running? This will only be used for local testing > purposes. > > Shaka, when the walls fell! rofl, i forget what movie is that from? > What distro? Debian GNU/Linux, unstable release > What arch? 2.4.18 kernel running on i686 arch Zach __________________________________ Do you Yahoo!? Yahoo! Mail - now with 250MB free storage. Learn more. http://info.mail.yahoo.com/mail_250 _______________________________________________ vanilla-list mailing list vanilla-list@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-list From ahn at orion.netrek.org Fri Jan 7 18:18:46 2005 From: ahn at orion.netrek.org (Dave Ahn) Date: Wed Jan 12 00:51:55 2005 Subject: [Vanilla List] expired and non-working clients Message-ID: <20050108001846.GA1954@orion.netrek.org> It looks like numerous clients have expired and/or are defunct. I am going to retire them and release a limited batch of new clients compiled from the latest sources using SourceForge's compile farm. Carlos, I'm going to send you some new keys soon. I'll also bring back an INL server on orion. See upcoming announcement for details. Dave _______________________________________________ vanilla-list mailing list vanilla-list@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-list From basic at us.netrek.org Tue Jan 11 15:20:03 2005 From: basic at us.netrek.org (Bob Tanner) Date: Wed Jan 12 00:51:55 2005 Subject: [Vanilla List] Migrate all vanilla-* email lists to netrek-* Message-ID: <200501111520.05743@www.mn-linux.org.or.transmuter.real-time.com> I think the below irc conversation sums up this posting: "netrek@us.netrek.org" for general discussions "netrek-dev@us.netrek.org" for development discussions "netrek-cvs@us.netrek.org" for CVS commit logs. I suggest toasting vanilla-announce, merging vanilla-clients into netrek-dev, vanilla-clue-pickup into netrek, vanilla-devel and vanilla-list into netrek-dev, vanilla-metaserver into netrek-dev. Expect to get several un-subscribe notifications and a couple subscribe notifications as I clean up the mailing lists. If you want details, please send me email off-list and I'll add you to the trouble ticket. -- Bob Tanner Key fingerprint = AB15 0BDF BCDE 4369 5B42 1973 7CF1 A709 2CC1 B288 _______________________________________________ vanilla-list mailing list vanilla-list@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-list From basic at us.netrek.org Tue Jan 11 15:20:03 2005 From: basic at us.netrek.org (Bob Tanner) Date: Wed Jan 12 00:51:55 2005 Subject: [Vanilla List] [Vanilla Ann] Migrate all vanilla-* email lists to netrek-* Message-ID: <200501111520.05743@www.mn-linux.org.or.transmuter.real-time.com> I think the below irc conversation sums up this posting: "netrek@us.netrek.org" for general discussions "netrek-dev@us.netrek.org" for development discussions "netrek-cvs@us.netrek.org" for CVS commit logs. I suggest toasting vanilla-announce, merging vanilla-clients into netrek-dev, vanilla-clue-pickup into netrek, vanilla-devel and vanilla-list into netrek-dev, vanilla-metaserver into netrek-dev. Expect to get several un-subscribe notifications and a couple subscribe notifications as I clean up the mailing lists. If you want details, please send me email off-list and I'll add you to the trouble ticket. -- Bob Tanner Key fingerprint = AB15 0BDF BCDE 4369 5B42 1973 7CF1 A709 2CC1 B288 _______________________________________________ vanilla-announce mailing list vanilla-announce@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-announce _______________________________________________ vanilla-list mailing list vanilla-list@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-list From bogus@does.not.exist.com Wed Jan 12 00:50:03 2005 From: bogus@does.not.exist.com () Date: Wed Jan 12 00:51:58 2005 Subject: No subject Message-ID: a shmget(); it was returning EIDRM, identifier removed. When trying to create the segment. ntservs were faithfully trying to start it. Eventually the condition seems to have gone away, and I was able to start a connection fine. Continuum runs Sparc Red Hat. % tail ERRORS X4: shutdown on signal 15 Fb: shutdown on signal 15 setupmem: Can't open shared memory, error 77 Daemon not running (err:77) Daemon not running (err:77) setupmem: Can't open shared memory, error 77 Daemon not running (err:77) Daemon not running (err:77) setupmem: Can't open shared memory, error 77 shmget: Identifier removed Daemon not running (err:77) Daemon not running (err:77) shmget: Identifier removed -- James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/ From bogus@does.not.exist.com Wed Jan 12 00:50:03 2005 From: bogus@does.not.exist.com () Date: Wed Jan 12 00:51:59 2005 Subject: No subject Message-ID: Quoting Jeffrey Nowakowski : > > > if (ping_allow_ghostbust && me->p_status == PALIVE && ping_ghostbust > > > > > > > Isn't it possible they bust in some other state? Shouldn't that be > > > "!= PFREE"? > > > > It would be redundant and in some cases harmful. > > > > Each of the other states already has explicit ghostbust behavior. > > (they're all at either 3 or 6 minutes for outfit and login, respectively) > > PALIVE is the only indeterminate length state that we care about > > ghostbust in. > > How would it be harmful? Ok, I didn't think that through. Yes, not getting any pings during the other states should shorten the process. > Consider that most people who bust get killed. And that's generally where the GB code finally kicks in. In the 3 minute POUTFIT window. > And what about observers? They have their own problems, one of which is someone walking away from the terminal. > In short, I think we need robust ping-ghostbust code that handles all > cases. That's what this thread is for.... > Sending ping requests down TCP: Perhaps it would be better to > ghostbust clients having TCP trouble, perhaps not. I still have reservations. That's why I want to try it out on one of the servers. I'm worried about false positives. > So for now I say make ghostbust code robust, and think about sending > ping via TCP later on. Umm.... I'm trying to make it more robust by moving it to TCP. I'm trying to increase the odds of the GB code detecting a hosed link in either direction. Right now all we have is ping and refit/login timeouts. And currently ping is on the very forgiving UDP link. The only other thing I can think of is switching GB code to threshold on loss percentage or rtt. > I guess I could modify a client to not send ping requests back. That works too. And you can synthesize data in the ping packet response as well. -------- this should be separate thread-------- > And while we're on the subject of pings, wouldn't it be useful to have > a ping stat for the last minute? Shorten the running average or have another field? Currently its lifetime average/std.dev. that's reported by '!' Clients usually calculate their own ping stats and can print out instantaneous pings. But really, are ping stats really important? There are only 2 cases where I've seen ping stats being used. The first is at the end of an INL game report, and the 2nd is for offence scummers to find someone to pick on. We'll there's 3. I use it to see how my network is doing, but I use instantaneous pings for that, not the running average. --Carlos V. From bogus@does.not.exist.com Wed Jan 12 00:50:03 2005 From: bogus@does.not.exist.com () Date: Wed Jan 12 00:51:59 2005 Subject: No subject Message-ID: Quoting Jeffrey Nowakowski : > > > if (ping_allow_ghostbust && me->p_status == PALIVE && ping_ghostbust > > > > > > > Isn't it possible they bust in some other state? Shouldn't that be > > > "!= PFREE"? > > > > It would be redundant and in some cases harmful. > > > > Each of the other states already has explicit ghostbust behavior. > > (they're all at either 3 or 6 minutes for outfit and login, respectively) > > PALIVE is the only indeterminate length state that we care about > > ghostbust in. > > How would it be harmful? Ok, I didn't think that through. Yes, not getting any pings during the other states should shorten the process. > Consider that most people who bust get killed. And that's generally where the GB code finally kicks in. In the 3 minute POUTFIT window. > And what about observers? They have their own problems, one of which is someone walking away from the terminal. > In short, I think we need robust ping-ghostbust code that handles all > cases. That's what this thread is for.... > Sending ping requests down TCP: Perhaps it would be better to > ghostbust clients having TCP trouble, perhaps not. I still have reservations. That's why I want to try it out on one of the servers. I'm worried about false positives. > So for now I say make ghostbust code robust, and think about sending > ping via TCP later on. Umm.... I'm trying to make it more robust by moving it to TCP. I'm trying to increase the odds of the GB code detecting a hosed link in either direction. Right now all we have is ping and refit/login timeouts. And currently ping is on the very forgiving UDP link. The only other thing I can think of is switching GB code to threshold on loss percentage or rtt. > I guess I could modify a client to not send ping requests back. That works too. And you can synthesize data in the ping packet response as well. -------- this should be separate thread-------- > And while we're on the subject of pings, wouldn't it be useful to have > a ping stat for the last minute? Shorten the running average or have another field? Currently its lifetime average/std.dev. that's reported by '!' Clients usually calculate their own ping stats and can print out instantaneous pings. But really, are ping stats really important? There are only 2 cases where I've seen ping stats being used. The first is at the end of an INL game report, and the 2nd is for offence scummers to find someone to pick on. We'll there's 3. I use it to see how my network is doing, but I use instantaneous pings for that, not the running average. --Carlos V. From bogus@does.not.exist.com Wed Jan 12 00:50:03 2005 From: bogus@does.not.exist.com () Date: Wed Jan 12 00:51:59 2005 Subject: No subject Message-ID: Quoting Jeffrey Nowakowski : > > > if (ping_allow_ghostbust && me->p_status == PALIVE && ping_ghostbust > > > > > > > Isn't it possible they bust in some other state? Shouldn't that be > > > "!= PFREE"? > > > > It would be redundant and in some cases harmful. > > > > Each of the other states already has explicit ghostbust behavior. > > (they're all at either 3 or 6 minutes for outfit and login, respectively) > > PALIVE is the only indeterminate length state that we care about > > ghostbust in. > > How would it be harmful? Ok, I didn't think that through. Yes, not getting any pings during the other states should shorten the process. > Consider that most people who bust get killed. And that's generally where the GB code finally kicks in. In the 3 minute POUTFIT window. > And what about observers? They have their own problems, one of which is someone walking away from the terminal. > In short, I think we need robust ping-ghostbust code that handles all > cases. That's what this thread is for.... > Sending ping requests down TCP: Perhaps it would be better to > ghostbust clients having TCP trouble, perhaps not. I still have reservations. That's why I want to try it out on one of the servers. I'm worried about false positives. > So for now I say make ghostbust code robust, and think about sending > ping via TCP later on. Umm.... I'm trying to make it more robust by moving it to TCP. I'm trying to increase the odds of the GB code detecting a hosed link in either direction. Right now all we have is ping and refit/login timeouts. And currently ping is on the very forgiving UDP link. The only other thing I can think of is switching GB code to threshold on loss percentage or rtt. > I guess I could modify a client to not send ping requests back. That works too. And you can synthesize data in the ping packet response as well. -------- this should be separate thread-------- > And while we're on the subject of pings, wouldn't it be useful to have > a ping stat for the last minute? Shorten the running average or have another field? Currently its lifetime average/std.dev. that's reported by '!' Clients usually calculate their own ping stats and can print out instantaneous pings. But really, are ping stats really important? There are only 2 cases where I've seen ping stats being used. The first is at the end of an INL game report, and the 2nd is for offence scummers to find someone to pick on. We'll there's 3. I use it to see how my network is doing, but I use instantaneous pings for that, not the running average. --Carlos V. From bogus@does.not.exist.com Wed Jan 12 00:50:03 2005 From: bogus@does.not.exist.com () Date: Wed Jan 12 00:52:00 2005 Subject: No subject Message-ID: Quoting Jeffrey Nowakowski : > > > if (ping_allow_ghostbust && me->p_status == PALIVE && ping_ghostbust > > > > > > > Isn't it possible they bust in some other state? Shouldn't that be > > > "!= PFREE"? > > > > It would be redundant and in some cases harmful. > > > > Each of the other states already has explicit ghostbust behavior. > > (they're all at either 3 or 6 minutes for outfit and login, respectively) > > PALIVE is the only indeterminate length state that we care about > > ghostbust in. > > How would it be harmful? Ok, I didn't think that through. Yes, not getting any pings during the other states should shorten the process. > Consider that most people who bust get killed. And that's generally where the GB code finally kicks in. In the 3 minute POUTFIT window. > And what about observers? They have their own problems, one of which is someone walking away from the terminal. > In short, I think we need robust ping-ghostbust code that handles all > cases. That's what this thread is for.... > Sending ping requests down TCP: Perhaps it would be better to > ghostbust clients having TCP trouble, perhaps not. I still have reservations. That's why I want to try it out on one of the servers. I'm worried about false positives. > So for now I say make ghostbust code robust, and think about sending > ping via TCP later on. Umm.... I'm trying to make it more robust by moving it to TCP. I'm trying to increase the odds of the GB code detecting a hosed link in either direction. Right now all we have is ping and refit/login timeouts. And currently ping is on the very forgiving UDP link. The only other thing I can think of is switching GB code to threshold on loss percentage or rtt. > I guess I could modify a client to not send ping requests back. That works too. And you can synthesize data in the ping packet response as well. -------- this should be separate thread-------- > And while we're on the subject of pings, wouldn't it be useful to have > a ping stat for the last minute? Shorten the running average or have another field? Currently its lifetime average/std.dev. that's reported by '!' Clients usually calculate their own ping stats and can print out instantaneous pings. But really, are ping stats really important? There are only 2 cases where I've seen ping stats being used. The first is at the end of an INL game report, and the 2nd is for offence scummers to find someone to pick on. We'll there's 3. I use it to see how my network is doing, but I use instantaneous pings for that, not the running average. --Carlos V. From bogus@does.not.exist.com Wed Jan 12 00:50:03 2005 From: bogus@does.not.exist.com () Date: Wed Jan 12 00:52:00 2005 Subject: No subject Message-ID: Quoting Jeffrey Nowakowski : > > > if (ping_allow_ghostbust && me->p_status == PALIVE && ping_ghostbust > > > > > > > Isn't it possible they bust in some other state? Shouldn't that be > > > "!= PFREE"? > > > > It would be redundant and in some cases harmful. > > > > Each of the other states already has explicit ghostbust behavior. > > (they're all at either 3 or 6 minutes for outfit and login, respectively) > > PALIVE is the only indeterminate length state that we care about > > ghostbust in. > > How would it be harmful? Ok, I didn't think that through. Yes, not getting any pings during the other states should shorten the process. > Consider that most people who bust get killed. And that's generally where the GB code finally kicks in. In the 3 minute POUTFIT window. > And what about observers? They have their own problems, one of which is someone walking away from the terminal. > In short, I think we need robust ping-ghostbust code that handles all > cases. That's what this thread is for.... > Sending ping requests down TCP: Perhaps it would be better to > ghostbust clients having TCP trouble, perhaps not. I still have reservations. That's why I want to try it out on one of the servers. I'm worried about false positives. > So for now I say make ghostbust code robust, and think about sending > ping via TCP later on. Umm.... I'm trying to make it more robust by moving it to TCP. I'm trying to increase the odds of the GB code detecting a hosed link in either direction. Right now all we have is ping and refit/login timeouts. And currently ping is on the very forgiving UDP link. The only other thing I can think of is switching GB code to threshold on loss percentage or rtt. > I guess I could modify a client to not send ping requests back. That works too. And you can synthesize data in the ping packet response as well. -------- this should be separate thread-------- > And while we're on the subject of pings, wouldn't it be useful to have > a ping stat for the last minute? Shorten the running average or have another field? Currently its lifetime average/std.dev. that's reported by '!' Clients usually calculate their own ping stats and can print out instantaneous pings. But really, are ping stats really important? There are only 2 cases where I've seen ping stats being used. The first is at the end of an INL game report, and the 2nd is for offence scummers to find someone to pick on. We'll there's 3. I use it to see how my network is doing, but I use instantaneous pings for that, not the running average. --Carlos V. From bogus@does.not.exist.com Wed Jan 12 00:50:03 2005 From: bogus@does.not.exist.com () Date: Wed Jan 12 00:52:00 2005 Subject: No subject Message-ID: Quoting Jeffrey Nowakowski : > > > if (ping_allow_ghostbust && me->p_status == PALIVE && ping_ghostbust > > > > > > > Isn't it possible they bust in some other state? Shouldn't that be > > > "!= PFREE"? > > > > It would be redundant and in some cases harmful. > > > > Each of the other states already has explicit ghostbust behavior. > > (they're all at either 3 or 6 minutes for outfit and login, respectively) > > PALIVE is the only indeterminate length state that we care about > > ghostbust in. > > How would it be harmful? Ok, I didn't think that through. Yes, not getting any pings during the other states should shorten the process. > Consider that most people who bust get killed. And that's generally where the GB code finally kicks in. In the 3 minute POUTFIT window. > And what about observers? They have their own problems, one of which is someone walking away from the terminal. > In short, I think we need robust ping-ghostbust code that handles all > cases. That's what this thread is for.... > Sending ping requests down TCP: Perhaps it would be better to > ghostbust clients having TCP trouble, perhaps not. I still have reservations. That's why I want to try it out on one of the servers. I'm worried about false positives. > So for now I say make ghostbust code robust, and think about sending > ping via TCP later on. Umm.... I'm trying to make it more robust by moving it to TCP. I'm trying to increase the odds of the GB code detecting a hosed link in either direction. Right now all we have is ping and refit/login timeouts. And currently ping is on the very forgiving UDP link. The only other thing I can think of is switching GB code to threshold on loss percentage or rtt. > I guess I could modify a client to not send ping requests back. That works too. And you can synthesize data in the ping packet response as well. -------- this should be separate thread-------- > And while we're on the subject of pings, wouldn't it be useful to have > a ping stat for the last minute? Shorten the running average or have another field? Currently its lifetime average/std.dev. that's reported by '!' Clients usually calculate their own ping stats and can print out instantaneous pings. But really, are ping stats really important? There are only 2 cases where I've seen ping stats being used. The first is at the end of an INL game report, and the 2nd is for offence scummers to find someone to pick on. We'll there's 3. I use it to see how my network is doing, but I use instantaneous pings for that, not the running average. --Carlos V. From bogus@does.not.exist.com Wed Jan 12 00:50:03 2005 From: bogus@does.not.exist.com () Date: Wed Jan 12 00:52:00 2005 Subject: No subject Message-ID: Quoting Jeffrey Nowakowski : > > > if (ping_allow_ghostbust && me->p_status == PALIVE && ping_ghostbust > > > > > > > Isn't it possible they bust in some other state? Shouldn't that be > > > "!= PFREE"? > > > > It would be redundant and in some cases harmful. > > > > Each of the other states already has explicit ghostbust behavior. > > (they're all at either 3 or 6 minutes for outfit and login, respectively) > > PALIVE is the only indeterminate length state that we care about > > ghostbust in. > > How would it be harmful? Ok, I didn't think that through. Yes, not getting any pings during the other states should shorten the process. > Consider that most people who bust get killed. And that's generally where the GB code finally kicks in. In the 3 minute POUTFIT window. > And what about observers? They have their own problems, one of which is someone walking away from the terminal. > In short, I think we need robust ping-ghostbust code that handles all > cases. That's what this thread is for.... > Sending ping requests down TCP: Perhaps it would be better to > ghostbust clients having TCP trouble, perhaps not. I still have reservations. That's why I want to try it out on one of the servers. I'm worried about false positives. > So for now I say make ghostbust code robust, and think about sending > ping via TCP later on. Umm.... I'm trying to make it more robust by moving it to TCP. I'm trying to increase the odds of the GB code detecting a hosed link in either direction. Right now all we have is ping and refit/login timeouts. And currently ping is on the very forgiving UDP link. The only other thing I can think of is switching GB code to threshold on loss percentage or rtt. > I guess I could modify a client to not send ping requests back. That works too. And you can synthesize data in the ping packet response as well. -------- this should be separate thread-------- > And while we're on the subject of pings, wouldn't it be useful to have > a ping stat for the last minute? Shorten the running average or have another field? Currently its lifetime average/std.dev. that's reported by '!' Clients usually calculate their own ping stats and can print out instantaneous pings. But really, are ping stats really important? There are only 2 cases where I've seen ping stats being used. The first is at the end of an INL game report, and the 2nd is for offence scummers to find someone to pick on. We'll there's 3. I use it to see how my network is doing, but I use instantaneous pings for that, not the running average. --Carlos V. From bogus@does.not.exist.com Wed Jan 12 00:50:03 2005 From: bogus@does.not.exist.com () Date: Wed Jan 12 00:52:00 2005 Subject: No subject Message-ID: Quoting Jeffrey Nowakowski : > > > if (ping_allow_ghostbust && me->p_status == PALIVE && ping_ghostbust > > > > > > > Isn't it possible they bust in some other state? Shouldn't that be > > > "!= PFREE"? > > > > It would be redundant and in some cases harmful. > > > > Each of the other states already has explicit ghostbust behavior. > > (they're all at either 3 or 6 minutes for outfit and login, respectively) > > PALIVE is the only indeterminate length state that we care about > > ghostbust in. > > How would it be harmful? Ok, I didn't think that through. Yes, not getting any pings during the other states should shorten the process. > Consider that most people who bust get killed. And that's generally where the GB code finally kicks in. In the 3 minute POUTFIT window. > And what about observers? They have their own problems, one of which is someone walking away from the terminal. > In short, I think we need robust ping-ghostbust code that handles all > cases. That's what this thread is for.... > Sending ping requests down TCP: Perhaps it would be better to > ghostbust clients having TCP trouble, perhaps not. I still have reservations. That's why I want to try it out on one of the servers. I'm worried about false positives. > So for now I say make ghostbust code robust, and think about sending > ping via TCP later on. Umm.... I'm trying to make it more robust by moving it to TCP. I'm trying to increase the odds of the GB code detecting a hosed link in either direction. Right now all we have is ping and refit/login timeouts. And currently ping is on the very forgiving UDP link. The only other thing I can think of is switching GB code to threshold on loss percentage or rtt. > I guess I could modify a client to not send ping requests back. That works too. And you can synthesize data in the ping packet response as well. -------- this should be separate thread-------- > And while we're on the subject of pings, wouldn't it be useful to have > a ping stat for the last minute? Shorten the running average or have another field? Currently its lifetime average/std.dev. that's reported by '!' Clients usually calculate their own ping stats and can print out instantaneous pings. But really, are ping stats really important? There are only 2 cases where I've seen ping stats being used. The first is at the end of an INL game report, and the 2nd is for offence scummers to find someone to pick on. We'll there's 3. I use it to see how my network is doing, but I use instantaneous pings for that, not the running average. --Carlos V. From bogus@does.not.exist.com Wed Jan 12 00:50:03 2005 From: bogus@does.not.exist.com () Date: Wed Jan 12 00:52:24 2005 Subject: No subject Message-ID: me->p_flags |= PFOBSERV; /* future clients may understand this */ I think it's pretty clear that it was added so clients could note observers in the player list and otherwise handle being in observer mode better. I know why it isn't sent or always set and can fix it. COW handles this pretty well. It will display the torp count and kills of the person observed in the dashboard (for dashboard != LAB). It looks like someone intended to sort the player list too: * TODO: * * Sort observers separatly: opserver if (pl->p_flags & PFOBSERV) is true. From bogus@does.not.exist.com Wed Jan 12 00:50:03 2005 From: bogus@does.not.exist.com () Date: Wed Jan 12 00:52:38 2005 Subject: No subject Message-ID: - update t-mode messages, they are outdated. Explicit instructions - find where the t-mode messages are defined, - analyse each message for relevance to today's players, - perform age analysis of player base [optional], - prepare hot list of messages to be deleted, - prepare equal or greater list of messages to be added, - adjust the source code, - recompile the server, - test the messages appear correctly and fit in the windows, - submit the patch to the team for review, - submit the final patch to the team for insertion into CVS. -- James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/ From bogus@does.not.exist.com Wed Jan 12 00:50:03 2005 From: bogus@does.not.exist.com () Date: Wed Jan 12 00:52:40 2005 Subject: No subject Message-ID: > Guess what, this just happens to be what I have installed. Me too. > Anyway, I looked at gum. I don't think glade uses the xml file to store the > layout of your program anymore, though glade will still parse the xml. From bogus@does.not.exist.com Wed Jan 12 00:50:03 2005 From: bogus@does.not.exist.com () Date: Wed Jan 12 00:52:40 2005 Subject: No subject Message-ID: Glade allows you to rapidly develope these interfaces, and can create source code in a variety of languages that will construct the interfaces for you. Glade can also be used in conjunction with libglade to dynamically create user interfaces from the XML description file that Glade creates. > However, glade now creates a totally different set of source files; there > isn't an xml file to describe the project anymore. Most of the stuff that > gets generated are stubs--you get to fill in the C code, mostly the callback > functions. When the interface is finished, you then usually save the project and build the C source files that will be used to generate the user interface. Integration with your project logic then follows. > I think we should just go with the latter approach. Trying to salvage > code from gum could be problematic, since we'd have to remove all the > existing widgets and add our own--easier to start from scratch. We could > probably use the stuff that James wrote to work with the config files--ie > the functions to write stuff to the xtrekrc. So you are saying we should just use recycle his GtkWidget definitions in the existing C code? Can't we just load his .xml file and do our changes in glade then save as C source? > I'm gonna worry about the windows build. I want to make sure I can build it > using cygwin. I've looked into it and yes, the libraries are available in > cygwin, though I haven't tried compiling it there. Ok and I can do the Linux build? I installed Cygwin once but couldn't get it working. A shell window would flash for a second then close. Last night I tried 3 times to get Sun Java tarball to download using dialup (~40MB), it would get to within ~100k of the final size and then hang :( argh. I tried directly ftp'ing but there is nothing there (ftp.sun.com). So after trying 2 mirror sites and HTTP via the Sun website I don't know what else to try. > So, if you can set me and zach up with CVS access, we can get goin. Cool. Zach zu22@andrew.cmu.edu "Blessed are those who have not seen and yet have faith." - John 20:29 From bogus@does.not.exist.com Wed Jan 12 00:50:03 2005 From: bogus@does.not.exist.com () Date: Wed Jan 12 00:52:56 2005 Subject: No subject Message-ID: advantageous if they are sufficiently skilled in *all* arenas. Perhaps the combat advantages will have less effect against some teams than others, but the whole point of the thing is to make it adapt to more situations than the humans can. Given the limitation regarding ability to adapt, the next best thing is to improve the small points. If a robot can kill 3 good players before dying, instead of 2, this may be the difference for 3 robots trying to take a planet with 6 defenders between succeeding and failing. If only 3 robots are necessary, even with 6 defenders, this allows 5 other robots to be doing other, more useful, things. You know... I suspect you may be believing that I am suggesting I am some sort of expert in Netrek. I'm not. My profession is not dog-fighting, nor is it strategic movement of troops. My profession is in design, innovation, and implementation of software. Rather than sitting out and telling me how twinky I am, you could be very useful as a technical advisor, if you didn't have the time, or inclination to take part in the actual coding. Perhaps I would not be successful in implementating a robot team that would be able to destroy any INL team. However, it is just possible that I can design the necessary infrastructure to do so. With a little input from people such as yourself, the chance of success improves dramatically. I never intended this to cause a fight. I also don't wish it to monopolize the development resources available on this list. I do wish it to create interest in Netrek, perhaps by academic sorts who would otherwise become bored, or disenchanted with the game. I do want it to succeed. Not to impress anybody, or to insult anybody. I want it to succeed, because it is a goal I set out to do around 10 years ago, but never had time to complete. It is a learning experience that might just benefit more people than just myself. Once complete, I wouldn't mind maintaining it as a sort of 'Iron Chef' forum. For anybody who doesn't watch the food channel, challengers from around the world challenge this set of 'Iron Chefs' to compete to see who can produce the meal that is best scored by influential people in Japan. The 'bot team, assuming it can win against a FreeBot team, would then become the first Iron 'Bot team. mark -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From bogus@does.not.exist.com Wed Jan 12 00:50:03 2005 From: bogus@does.not.exist.com () Date: Wed Jan 12 00:53:10 2005 Subject: No subject Message-ID: > The problem with full updates messing up COW users is not > caused by genspkt.c. > The version 1.20 that continuum is using just doesn't exhibit > it because the no flag packet bug covers it up. The real > problem is that the increase to 32 players made the full > update packet larger than a 768 byte buffer COW uses. > The solution is to increase the buffer size in COW, not add > bugs to the server that make the problem disappear for a bit. And based on these two segments: #define BUFSIZE 1024 char buf[BUFSIZE]; and later in doRead() count = read(asock, buf, BUFSIZE - /* space for packet frag */ BUFSIZE / 4); I'm assuming all you did was increase the BUFSIZE constant? I haven't had time to reproduce this in a debugger, but I figured it was something like this. Most of the problems I've seen in the netrek code have been buffer problems. :( From David.Watson at team17.com Wed Jan 12 05:07:04 2005 From: David.Watson at team17.com (David Watson) Date: Wed Jan 12 05:11:34 2005 Subject: [netrek-dev] Re: [Vanilla Devel] bitkeeper In-Reply-To: <200501061121.12507@www.mn-linux.org.or.transmuter.real-tim e.com> References: <20050104085546.24154.qmail@web21127.mail.yahoo.com> <20050104085546.24154.qmail@web21127.mail.yahoo.com> Message-ID: <5.2.0.9.0.20050112110246.05388eb0@mailgate.team17.com> On a quick reading of the comparison I'm a little unsettled by the gratis license, issues are raised at: http://linuxmafia.com/faq/Apps/scm.html While not being a developer myself I would like read access to the repository to move my server up from pl7 (latest on the website) Cheers Dave From tanner at real-time.com Wed Jan 12 13:09:33 2005 From: tanner at real-time.com (Bob Tanner) Date: Wed Jan 12 13:11:14 2005 Subject: [netrek-dev] Testing netrek-dev@us.netrek.org Message-ID: <20050112190933.GA6991@real-time.com> From e at hietbrink.org Wed Jan 12 14:21:50 2005 From: e at hietbrink.org (E. Hietbrink) Date: Wed Jan 12 16:46:59 2005 Subject: [netrek-dev] testing netrek-dev@us.netrek.org ==> ignore. Message-ID: <41E586DE.4040902@hietbrink.org> test From mark at mark.mielke.cc Wed Jan 12 15:21:59 2005 From: mark at mark.mielke.cc (mark@mark.mielke.cc) Date: Wed Jan 12 16:47:01 2005 Subject: [netrek-dev] Re: [Vanilla Devel] bitkeeper In-Reply-To: <5.2.0.9.0.20050112110246.05388eb0@mailgate.team17.com> References: <20050104085546.24154.qmail@web21127.mail.yahoo.com> <20050104085546.24154.qmail@web21127.mail.yahoo.com> <5.2.0.9.0.20050112110246.05388eb0@mailgate.team17.com> Message-ID: <20050112212159.GA30959@mark.mielke.cc> On Wed, Jan 12, 2005 at 11:07:04AM +0000, David Watson wrote: > On a quick reading of the comparison I'm a little unsettled by the > gratis license, issues are raised at: > http://linuxmafia.com/faq/Apps/scm.html > While not being a developer myself I would like read access to the > repository to move my server up from pl7 (latest on the website) I recall reading that the respository is SCCS compatible. Never tried it myself... Do you work in the SCM business? If you don't, I think you can use it for free. It's people like me, who are in the SCM business, who have to either negotiate with Larry, or pay the license... Cheers, mark -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From vanillatrek at yahoo.com Wed Jan 12 21:24:27 2005 From: vanillatrek at yahoo.com (Zach) Date: Wed Jan 12 21:26:18 2005 Subject: [netrek-dev] testing netrek-dev Message-ID: <20050113032427.33672.qmail@web21121.mail.yahoo.com> testing netrek-dev __________________________________ Do you Yahoo!? Yahoo! Mail - Easier than ever with enhanced search. Learn more. http://info.mail.yahoo.com/mail_250 From David.Watson at team17.com Thu Jan 13 04:43:01 2005 From: David.Watson at team17.com (David Watson) Date: Thu Jan 13 04:46:20 2005 Subject: [netrek-dev] Re: [Vanilla Devel] bitkeeper In-Reply-To: <20050112212159.GA30959@mark.mielke.cc> References: <5.2.0.9.0.20050112110246.05388eb0@mailgate.team17.com> <20050104085546.24154.qmail@web21127.mail.yahoo.com> <20050104085546.24154.qmail@web21127.mail.yahoo.com> <5.2.0.9.0.20050112110246.05388eb0@mailgate.team17.com> Message-ID: <5.2.0.9.0.20050113103832.05950678@mailgate.team17.com> Its not the competitive clause, just the mention of historically changing the licence and part of the gratis license is an obligation to upgrade (and thus be bound by the new agreement) I imagine that practically we don't have anything to worry about, its just something that seems a little unsettling. Dave From vanillatrek at yahoo.com Thu Jan 20 08:34:46 2005 From: vanillatrek at yahoo.com (Zach) Date: Thu Jan 20 08:41:13 2005 Subject: [netrek-dev] memory leaks? Message-ID: <20050120143447.33683.qmail@web21121.mail.yahoo.com> Is anyone interested in the Vanilla code being audited for memory leaks? I am learning about this and thought it could be a good learning experience. Or has this already been done? Zach __________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com From tanner at real-time.com Fri Jan 21 23:11:33 2005 From: tanner at real-time.com (Bob Tanner) Date: Fri Jan 21 23:12:24 2005 Subject: [netrek-dev] netrek-dev into gmane gateway Message-ID: <20050122051133.GA14431@real-time.com> I've added netrek-dev to the gmane archive. Info below. Gmane is a mail-to-news portal that never expires its messages. It therefore also functions as a mailing list archive. It's a bi-directional gateway, but Gmane verifies that its users' email addresses are valid before passing the messages through the news-to-mail gateway. (Groups can also be made "read-only", which means that Gmane won't forward any messages at all to the mailing list.) Gmane can encrypt addresses to make address harvesting difficult, and heeds X-No-Archive and related headers. If you wish to import older archives into Gmane, send a message to the Gmane administrators with the URL of a Unix mbox archive of the mailing list. The following parameters are set for this mailing list: * Newsgroup name: gmane.games.netrek.devel * Mailing list address: netrek-dev@us.netrek.org * The gateway is bi-directional * Address encryption is on * Spam detection is on * The list is described as: "Netrek developer mailing list" * News URL: news://news.gmane.org/gmane.games.netrek.devel * Web URL: http://news.gmane.org/gmane.games.netrek.devel This newsgroup will be created when the first message from the mailing list arrives. For more information about the Gmane project, go to . -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org, Minnesota, Linux | Fax : (952)943-8500 http://www.tcwug.org, Minnesota, Wireless | Coding isn't a crime. Fingerprint: 02E0 2734 A1A1 DBA1 0E15 623D 0036 7327 93D9 7DA3 From ahn at orion.netrek.org Wed Jan 26 10:36:03 2005 From: ahn at orion.netrek.org (Dave Ahn) Date: Wed Jan 26 10:28:17 2005 Subject: [netrek-dev] genocide/www down until Monday or so Message-ID: <20050126163603.GA877@orion.netrek.org> Hi folks, There has been a network service interruption which has taken genocide offline. We're workng on relocating the server and expect to have things back up around Monday. Also, most of the public *.psychosis.net clue servers will be relocated to the same server. I'll make an updated announcement as soon as I'm able. Dave From xyzzy Wed Jan 12 00:53:10 2005 From: xyzzy (Trent Piepho) Date: Wed Jan 12 00:53:10 2005 Subject: [Vanilla List] continuum bugs and cow bugs Message-ID: The downgrade of genspkt.c on continuum has caused a few problems. The cod= e to indicate observers is now missing. When there are lots of observers, people with one column player lists run out of room for real players. Some clients can turn off observers in the player list to make room, but that do= n't work. The problem with stats updating has been re-introduced. It still sometimes takes 10 minutes for everyone's stats to be displayed after login. And there is a bug where player flag packets are never sent. All these bugs were fixed in the latest (like a year old!) version. The problem with full updates messing up COW users is not caused by genspkt= .c. The version 1.20 that continuum is using just doesn't exhibit it because th= e no flag packet bug covers it up. The real problem is that the increase to = 32 players made the full update packet larger than a 768 byte buffer COW uses. The solution is to increase the buffer size in COW, not add bugs to the ser= ver that make the problem disappear for a bit. If you are going to release a now cow, how about fixing this bug? From tanner Wed Jan 12 00:53:10 2005 From: tanner (Bob Tanner) Date: Wed Jan 12 00:53:10 2005 Subject: [Vanilla List] full updates Message-ID: <20020621230703.W3943@real-time.com> Changing the doRead() to read BUFSIZE bytes fixes the full update bug. Full= game on continuum and I logged in 10 obs, hit =3D for full update and the client doesn't crash, or randon net planets, like it use to. James, does continuum have 1.20 genpkt.c or 1.21? Anyways, did the same thing on our private netrek server, which is running cvs-snapshot of 06/20/2002 with 10 obs and 16 players, full updates don't c= rash the client. But I'm still seeing the very slow updated to player stats in the player wi= ndow. If I request a full update shouldn't I get all the player stats fairly quic= kly? -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org, Minnesota, Linux | Fax : (952)943-8500 http://www.tcwug.org, Minnesota, Wireless | Coding isn't a crime. Key fingerprint =3D AB15 0BDF BCDE 4369 5B42 1973 7CF1 A709 2CC1 B288 From xyzzy Wed Jan 12 00:53:11 2005 From: xyzzy (Trent Piepho) Date: Wed Jan 12 00:53:11 2005 Subject: [Vanilla List] full updates In-Reply-To: <20020621230703.W3943@real-time.com> Message-ID: On Fri, 21 Jun 2002, Bob Tanner wrote: > Changing the doRead() to read BUFSIZE bytes fixes the full update bug. Fu= ll game You should increase BUFSIZE. > on continuum and I logged in 10 obs, hit =3D for full update and the clie= nt > doesn't crash, or randon net planets, like it use to. You should actually check the packet size. > But I'm still seeing the very slow updated to player stats in the player = window. > > If I request a full update shouldn't I get all the player stats fairly qu= ickly? Nope.