From jrd at gerdesas.com  Fri May  1 00:00:23 2009
From: jrd at gerdesas.com (John R. Dennison)
Date: Fri, 1 May 2009 00:00:23 -0500
Subject: [netrek-dev] Auto-update
In-Reply-To: <20090501040958.GJ25309@thorne.id.au>
References: <ecfa260c0904302042o53cdf293t337f76ccf4e755b3@mail.gmail.com>
	<20090501040958.GJ25309@thorne.id.au>
Message-ID: <20090501050023.GK7577@frodo.gerdesas.com>

On Fri, May 01, 2009 at 02:09:58PM +1000, Stephen Thorne wrote:
> On 2009-04-30, Zachary Uram wrote:
> > Any ideas?
> 
> Non-problem. Package manager does this already.

	Only if it's repo'd.  Is this the case for all currently
	available *nix clients?




							John

-- 
"I'm sorry but our engineers do not have phones."
As stated by a Network Solutions Customer Service representative when asked to
be put through to an engineer.

"My other computer is your windows box."
                                     Ralf Hildebrandt
<sxem> trying to play sturgeon while it's under attack is apparently not fun.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20090501/133981d8/attachment.pgp 

From quozl at us.netrek.org  Fri May  1 00:11:08 2009
From: quozl at us.netrek.org (James Cameron)
Date: Fri, 1 May 2009 15:11:08 +1000
Subject: [netrek-dev] Auto-update
In-Reply-To: <20090501050023.GK7577@frodo.gerdesas.com>
References: <ecfa260c0904302042o53cdf293t337f76ccf4e755b3@mail.gmail.com>
	<20090501040958.GJ25309@thorne.id.au>
	<20090501050023.GK7577@frodo.gerdesas.com>
Message-ID: <20090501051107.GN5982@us.netrek.org>

On Fri, May 01, 2009 at 12:00:23AM -0500, John R. Dennison wrote:
> 	Only if it's repo'd.  Is this the case for all currently
> 	available *nix clients?

netrek-client-cow: yes

netrek-client-pygame: no, because I lack Python on Debian packaging foo
but would welcom einput.

BRMH: no packages, this is a client for fanatics.  ;-)

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


From chris.lukassen at gmail.com  Fri May  1 15:40:07 2009
From: chris.lukassen at gmail.com (Chris Lukassen)
Date: Fri, 1 May 2009 22:40:07 +0200
Subject: [netrek-dev] netrek-dev Digest, Vol 51, Issue 1
In-Reply-To: <mailman.1.1241197203.25609.netrek-dev@us.netrek.org>
References: <mailman.1.1241197203.25609.netrek-dev@us.netrek.org>
Message-ID: <E3AA642F-F4D8-4EA6-B4AA-908F3B8585A9@gmail.com>

Hi

Catching up after Zachs mail, MacTrek 1.4 clients check an xml file at  
sourceforge to see if they are up to date. The dns work around seems  
to work for 1.4 clients, merged Bob's change with the trunk. Will try  
to put out a new version sometime soon.

regards

C


From quozl at us.netrek.org  Fri May  1 19:49:43 2009
From: quozl at us.netrek.org (James Cameron)
Date: Sat, 2 May 2009 10:49:43 +1000
Subject: [netrek-dev] netrek-dev Digest, Vol 51, Issue 1
In-Reply-To: <E3AA642F-F4D8-4EA6-B4AA-908F3B8585A9@gmail.com>
References: <mailman.1.1241197203.25609.netrek-dev@us.netrek.org>
	<E3AA642F-F4D8-4EA6-B4AA-908F3B8585A9@gmail.com>
Message-ID: <20090502004943.GA5594@us.netrek.org>

On Fri, May 01, 2009 at 10:40:07PM +0200, Chris Lukassen wrote:
> Catching up after Zachs mail, MacTrek 1.4 clients check an xml file at  
> sourceforge to see if they are up to date.

Indeed they do.  I ran 1.4 on a MacBook 10.4 while monitoring all
network traffic, and found a request to
http://mactrek.sourceforge.net/MacTrekLatestVersion.plist in parallel
with the second metaserver query to orion.netrek.org.

> The dns work around seems  
> to work for 1.4 clients, merged Bob's change with the trunk.

Good.  I also set up a temporary metaserver to catch the queries.  Saw a
few.

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


From akb+lists.netrek-dev at mirror.to  Sun May  3 03:00:15 2009
From: akb+lists.netrek-dev at mirror.to (Andrew K. Bressen)
Date: Sun, 03 May 2009 04:00:15 -0400
Subject: [netrek-dev] netrek-dev Digest, Vol 51, Issue 1
In-Reply-To: <E3AA642F-F4D8-4EA6-B4AA-908F3B8585A9@gmail.com> (Chris
	Lukassen's message of "Fri, 1 May 2009 22:40:07 +0200")
References: <mailman.1.1241197203.25609.netrek-dev@us.netrek.org>
	<E3AA642F-F4D8-4EA6-B4AA-908F3B8585A9@gmail.com>
Message-ID: <0q63giboq8.fsf@mirror.to>


Chris Lukassen <chris.lukassen at gmail.com> writes:
> sourceforge to see if they are up to date. The dns work around seems  
> to work for 1.4 clients, merged Bob's change with the trunk. Will try  
> to put out a new version sometime soon.

Great!

Others please check me on this, I believe that RSA is now deprecated for
Netrek, which means that if MacTrek is only using libgmp to do RSA
and not for any other purpose, then that dependancy can be removed. 
I remember that osx libgmp issues were causing some problems...

  --akb



From basic at us.netrek.org  Mon May  4 15:46:16 2009
From: basic at us.netrek.org (Bob Tanner)
Date: Mon, 4 May 2009 15:46:16 -0500
Subject: [netrek-dev] netrek-dev Digest, Vol 51, Issue 1
References: <E3AA642F-F4D8-4EA6-B4AA-908F3B8585A9@gmail.com>
	<0q63giboq8.fsf@mirror.to>
Message-ID: <gtnk6o$49u$1@ger.gmane.org>

On 2009-05-03 03:00:15 -0500, 
akb+lists.netrek-dev at mirror.to (Andrew K. 
Bressen) said:

> I remember that osx libgmp issues were causing some problems...

The patch I provide removes gmp from the xcode project and uses the 
darwin port version of gmp which works for osx-10.5/Intel.

I do not have anything but 10.5.x/Intel to test on. So your results may 
vary on only OS release and the ppc platform.

-- 
Bob Tanner <basic at us.netrek.org>          
Key fingerprint = F785 DDFC CF94 7CE8 AA87 3A9D 3895 26F1 0DDB E378




From quozl at us.netrek.org  Tue May  5 04:50:34 2009
From: quozl at us.netrek.org (James Cameron)
Date: Tue, 5 May 2009 19:50:34 +1000
Subject: [netrek-dev] Version Packet
In-Reply-To: <20090421003536.GA14614@us.netrek.org>
References: <20090421003536.GA14614@us.netrek.org>
Message-ID: <20090505095034.GA18082@us.netrek.org>

On Tue, Apr 21, 2009 at 10:35:36AM +1000, James Cameron wrote:
> Client developers may now consider RSA optional, and until the new
> identification packets are in place building with RSA should continue.
> 
> Server developers will retain RSA in the code.  We'll be working to add
> a way to identify client versions for statistics.

netrek-client-cow sends a CP_MESSAGE to server after SP_PICKOK which
contains a own slot number, group (MINDIV | MCONFIG) and text
"@version", where version is the version number.

S->C SP_MASK      mask=15,
S->C SP_PICKOK    state=1,
C->S CP_MESSAGE   group=66, indiv=0, mesg="@3.2.10",
C->S CP_UDP_REQ   request=1, connmode=0, port=17784,

Netrek XP also does the same, in dmessage.c, sendVersion().

So I propose that the client name be *appended* to the version string,
and the server to process the message into logs.

The text is handled in ntserv/socket.c in function clientVersion, where
it is duplicated and stored in a global variable version.  At this point
it can be logged.

The only apparent use is in ntserv/features.c where it is used to
compare against the features file, in TellClient, but this function is
only called *after* successful RSA verification in decryptRSAPacket.

This is an entirely different read of the features file to the one done
in ntserv/feature.c.  ;-)

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


From quozl at us.netrek.org  Wed May  6 03:06:26 2009
From: quozl at us.netrek.org (James Cameron)
Date: Wed, 6 May 2009 18:06:26 +1000
Subject: [netrek-dev] [PATCH] BRMH, add new client identification feature
Message-ID: <20090506080626.GA16507@us.netrek.org>

The attached patch is the last of a series, this time to BRMH.

The previous patches were to netrek-server, netrek-client-cow, Netrek XP
2009, and netrek-client-pygame.

The patch uses the old feature support which sends client version, to
also send client name.

The server did not use the version string for clients that have feature
packet support.  The server now logs the version string.

-- 
James Cameron    mailto:quozl at us.netrek.org     http://quozl.netrek.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: brmh-client-id.patch
Type: text/x-diff
Size: 977 bytes
Desc: not available
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20090506/d2bb1046/attachment.patch 

From quozl at us.netrek.org  Wed May  6 04:13:26 2009
From: quozl at us.netrek.org (James Cameron)
Date: Wed, 6 May 2009 19:13:26 +1000
Subject: [netrek-dev] Version Packet
In-Reply-To: <20090505095034.GA18082@us.netrek.org>
References: <20090421003536.GA14614@us.netrek.org>
	<20090505095034.GA18082@us.netrek.org>
Message-ID: <20090506091326.GC18677@us.netrek.org>

The chosen implementation is that the client sends the name and the
version in the same message.  This is optional.  This would usually
occur after SP_PICKOK.  The protocol definition in packets.h has been
changed.

The new behaviour in the clients is compatible with existing servers.

The new behaviour in the server is compatible with existing clients.
The logs will contain version numbers without client names.

(The new behaviour is potentially incompatible with any old server that
does not use feature packets, if the server has a features file using
the very old features format that predated the SP_FEATURE/CP_FEATURE
pair.  In those days the features were exchanged using
SP_MESSAGE/CP_MESSAGE packets with MCONFIG set and a SRV header.  The
result of the incompatibility would be failure to match feature lines by
client version number.)

Thanks to those who participated in the IRC discussion earlier today.

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


From quozl at us.netrek.org  Wed May  6 18:38:07 2009
From: quozl at us.netrek.org (James Cameron)
Date: Thu, 7 May 2009 09:38:07 +1000
Subject: [netrek-dev] Meaning of "Open" on Metaserver Lists
Message-ID: <20090506233807.GB19683@us.netrek.org>

The patch here changes the meaning of "OPEN" as shown by the clients on
metaserver window.

Historically the window would show servers that had only just lost all
their clients.  These would be shown as "OPEN" with no players.

"Nobody" meant the server was not even running, which happens after the
one minute timeout for daemon shutdown.

Are we all agreed to hide the fact that a server was only just active?

If so, it may be simpler for the metaserver to just not send open if the
server has no players.

-- 
James Cameron    mailto:quozl at us.netrek.org     http://quozl.netrek.org/
-------------- next part --------------
An embedded message was scrubbed...
From: Bill Balcerski <modemhero at users.sourceforge.net>
Subject: [netrek-cvs] client/netrekxp/src parsemeta.c,1.44,1.45
Date: Wed, 06 May 2009 21:40:52 +0000
Size: 4273
Url: http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20090507/9e6bd5b6/attachment.eml 

From quozl at us.netrek.org  Wed May  6 19:41:13 2009
From: quozl at us.netrek.org (James Cameron)
Date: Thu, 7 May 2009 10:41:13 +1000
Subject: [netrek-dev] Meaning of "Open" on Metaserver Lists
In-Reply-To: <20090506233807.GB19683@us.netrek.org>
References: <20090506233807.GB19683@us.netrek.org>
Message-ID: <20090507004113.GE19683@us.netrek.org>

I retract that, version_s is only for multicast discovery.

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


From basic at us.netrek.org  Fri May  8 15:10:39 2009
From: basic at us.netrek.org (Bob Tanner)
Date: Fri, 8 May 2009 15:10:39 -0500
Subject: [netrek-dev] OSXTrek 10.4 and ppc?
Message-ID: <gu23jv$nt7$1@ger.gmane.org>

Until we hear back from Chris (primary developer of Mactrek) I'm 
forging ahead on my learning how to write code for osx.

First issue:

I am all 10.5/i386, I installed the 10.4 SDK, changed the xcode options 
to 10.4/i386, and compiled up a test application, forced Quozl to test 
it with disasterous results.

I'm looking for someone who is still 10.4/i386 who can do compiling so 
I can figure out how to make xcode on 10.5 make 10.4 compatibile .apps.

The MacTrek binary is 10.4 and it works under 10.5. An option might be 
to just to compile for 10.4.

Second issue:

Anyone with ppc still? Do we even move forward supporting this architecture?

-- 
Bob Tanner <basic at us.netrek.org>          
Key fingerprint = F785 DDFC CF94 7CE8 AA87 3A9D 3895 26F1 0DDB E378




From billbalcerski at gmail.com  Sat May  9 16:23:45 2009
From: billbalcerski at gmail.com (Bill Balcerski)
Date: Sat, 9 May 2009 17:23:45 -0400
Subject: [netrek-dev] RSA Infrastructure Deprecated
In-Reply-To: <20090421003536.GA14614@us.netrek.org>
References: <20090421003536.GA14614@us.netrek.org>
Message-ID: <45ab86180905091423s2338bd02n822e858e03fa5cf1@mail.gmail.com>

On Mon, Apr 20, 2009 at 8:35 PM, James Cameron <quozl at us.netrek.org> wrote:
> RES-RSA infrastructure is now deprecated.
>
> Client developers may now consider RSA optional, and until the new
> identification packets are in place building with RSA should continue.
>
Client identification packets now in place in server side.  I've
removed RSA from the
Windows client, using the new identification system instead.

Bill


From quozl at us.netrek.org  Sat May  9 19:24:21 2009
From: quozl at us.netrek.org (James Cameron)
Date: Sun, 10 May 2009 10:24:21 +1000
Subject: [netrek-dev] RSA Infrastructure Deprecated
In-Reply-To: <45ab86180905091423s2338bd02n822e858e03fa5cf1@mail.gmail.com>
References: <20090421003536.GA14614@us.netrek.org>
	<45ab86180905091423s2338bd02n822e858e03fa5cf1@mail.gmail.com>
Message-ID: <20090510002421.GC18470@us.netrek.org>

On Sat, May 09, 2009 at 05:23:45PM -0400, Bill Balcerski wrote:
> On Mon, Apr 20, 2009 at 8:35 PM, James Cameron <quozl at us.netrek.org> wrote:
> > RES-RSA infrastructure is now deprecated.
> >
> > Client developers may now consider RSA optional, and until the new
> > identification packets are in place building with RSA should continue.
> >
> Client identification packets now in place in server side.  I've
> removed RSA from the
> Windows client, using the new identification system instead.

Ok.  I plan to have the server report to ALL the version obtained from
either RSA or the new client version method.  Yet to figure out exactly
how.

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


From netrek at gmail.com  Sat May  9 20:01:16 2009
From: netrek at gmail.com (Zachary Uram)
Date: Sat, 9 May 2009 21:01:16 -0400
Subject: [netrek-dev] RSA Infrastructure Deprecated
In-Reply-To: <20090510002421.GC18470@us.netrek.org>
References: <20090421003536.GA14614@us.netrek.org>
	<45ab86180905091423s2338bd02n822e858e03fa5cf1@mail.gmail.com>
	<20090510002421.GC18470@us.netrek.org>
Message-ID: <ecfa260c0905091801r5d733144r47138ca684617e49@mail.gmail.com>

On Sat, May 9, 2009 at 8:24 PM, James Cameron <quozl at us.netrek.org> wrote:
>
> Ok.  I plan to have the server report to ALL the version obtained from
> either RSA or the new client version method.  Yet to figure out exactly
> how.

Perhaps send a feature packet just after RSA negotiation would occur?

Zach


From quozl at us.netrek.org  Sat May  9 22:59:21 2009
From: quozl at us.netrek.org (James Cameron)
Date: Sun, 10 May 2009 13:59:21 +1000
Subject: [netrek-dev] RSA Infrastructure Deprecated
In-Reply-To: <20090510002421.GC18470@us.netrek.org>
References: <20090421003536.GA14614@us.netrek.org>
	<45ab86180905091423s2338bd02n822e858e03fa5cf1@mail.gmail.com>
	<20090510002421.GC18470@us.netrek.org>
Message-ID: <20090510035921.GF18470@us.netrek.org>

On Sun, May 10, 2009 at 10:24:21AM +1000, James Cameron wrote:
> Ok.  I plan to have the server report to ALL the version obtained from
> either RSA or the new client version method.  Yet to figure out exactly
> how.

Completed.

"CLIENT" command provides user interface.

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


From netrek at gmail.com  Mon May 18 09:30:30 2009
From: netrek at gmail.com (Zachary Uram)
Date: Mon, 18 May 2009 10:30:30 -0400
Subject: [netrek-dev] Netrek Game On! memory usage issue
Message-ID: <ecfa260c0905180730j1c80bec4q9ac4da0fecb20394@mail.gmail.com>

Someone in IRC (I think it was Bob Tanner) mentioned that running the
poller application under OS X was eating up over 300MB of system
memory. I talked to Jeremy and he said this should not be happening
and that there should not be any memory leaks in his app. Here is a
screenshot he sent me (he is running MS Windows Vista I think) showing
only 19MB of memory being used:

http://www.jesujuva.org/mem-usage.jpg

Zach


From netrek at gmail.com  Mon May 18 15:00:04 2009
From: netrek at gmail.com (Zachary Uram)
Date: Mon, 18 May 2009 16:00:04 -0400
Subject: [netrek-dev] Fwd: [netrek-forever] Netrek for the iPhone
In-Reply-To: <7BEAF6D4-1BCF-4F29-82D5-48C4D8AC3141@yahoo.com>
References: <503006d6-1013-4f54-b6a8-b4b9b8e38f43@f16g2000vbf.googlegroups.com>
	<BLU111-W21FBC5AF00F516C48D776CCB5D0@phx.gbl>
	<ecfa260c0905171710q39829ed7o43cdd6d27d15fa52@mail.gmail.com>
	<BLU111-W58409DEE08F59F00CFAA0BCB5A0@phx.gbl>
	<EA40BCD5-59C4-4794-B731-1A377692396D@gmail.com>
	<BLU111-W300751462BC03B0C0B242ACB5A0@phx.gbl>
	<7070E83E-06A0-40A1-B44F-CF14E7F1296B@gmail.com>
	<7BEAF6D4-1BCF-4F29-82D5-48C4D8AC3141@yahoo.com>
Message-ID: <ecfa260c0905181300i5b777e37macfae4f23b4b6690@mail.gmail.com>

---------- Forwarded message ----------
From: Brendan Patterson <brendanpatterson at yahoo.com>
Date: Mon, May 18, 2009 at 12:50 PM
Subject: [netrek-forever] Netrek for the iPhone
To: netrek-forever at googlegroups.com



An iPhone Netrek client would quickly add at least thousands of
players, not to mention whomever wrote it would very likely get rich
quick even if you sold a $0.99 version :)

As it seems the Mac client is already written in Objective C that's
probably a huge jump start. What license is that code under? I suppose
you could still sell it if it's GPL, you'd just have to release the
source.

It would indeed be the ultimate iPhone game - especially if you could
have a stand alone mode which was just bots.

We all know that an iPhone has many times the computing power needed.
The trick would be a clever UI though this is where the touch screen
and gestures get really exciting.

Ideas (please add your own)
* stand alone mode so you don't need a network or server necessarily
* touch and drag your ship ( a vector indicating speed would appear)
the longer the drag the greater the speed.
* tap to fire torpedos
* tap with two fingers for phaser
* pull three fingers straight down for repair mode
* twist two fingers clock wise for shields up
* twist two fingers counter clockwise for shields down
* just like photos of course two fingers squeezing out would be zoom
in - opposite zoom out
* you can swipe to flick between galaxy overview and close in view

* the only thing that's not obvious is how to communicate, but you
could have the canned messages easily enough - 'transporting 4 armies
to earth'

Anyway these are just a few quick ideas. I'm sure you guys can come up
with better ones. Here is a mockup:
http://img.skitch.com/20090518-kckhkbttghxqpmmcngqi71h3e4.jpg


--~--~---------~--~----~------------~-------~--~----~
To post send mail here: netrek-forever at googlegroups.com
More info: http://tinyurl.com/netrek
-~----------~----~----~----~------~----~------~--~---





Of course the thing that can't be stressed enough is that the
refreshed StarTrek franchise is creating a whole new fan base and
revitalizing the old one. Free marketing galore :)

Good times!






-- 
<><
J.S. Bach - Primus inter pares
Soli Deo Gloria
http://www.jesujuva.org
><>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: iphone-netrek.jpg
Type: image/jpeg
Size: 37739 bytes
Desc: not available
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20090518/998ce381/attachment-0001.jpg 

From quozl at us.netrek.org  Mon May 18 18:36:28 2009
From: quozl at us.netrek.org (James Cameron)
Date: Tue, 19 May 2009 09:36:28 +1000
Subject: [netrek-dev] Netrek Game On! memory usage issue
In-Reply-To: <ecfa260c0905180730j1c80bec4q9ac4da0fecb20394@mail.gmail.com>
References: <ecfa260c0905180730j1c80bec4q9ac4da0fecb20394@mail.gmail.com>
Message-ID: <20090518233628.GD17572@us.netrek.org>

On Mon, May 18, 2009 at 10:30:30AM -0400, Zachary Uram wrote:
> Someone in IRC (I think it was Bob Tanner) mentioned that running the
> poller application under OS X was eating up over 300MB of system
> memory.

Bob, take a look at OS X's Java VM for a hello world.  Exclude cache.

> I talked to Jeremy and he said this should not be happening
> and that there should not be any memory leaks in his app.

Good.

> Here is a
> screenshot he sent me (he is running MS Windows Vista I think) showing
> only 19MB of memory being used:
> 
> http://www.jesujuva.org/mem-usage.jpg

Irrelevant.  It is the trend that is important.  Measure the usage at
hourly intervals.  Or if this was taken after some hours say so.

I wouldn't be surprised to find it is a feature of the virtual machine
in use.  Zach, why don't you load up a Java VM yourself and test it out,
that way we'd get the Linux data point.

As another data point, the metaget program that I use takes a peak of
2Mb virtual memory, 644Kb physical memory, and is 13k on disk.  The
large difference between the on-disk size and the peak virtual memory
size is caused by the very large C run time library.

Jeremy, are you on the netrek-dev mailing list yet?

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


From akb+lists.netrek-dev at mirror.to  Tue May 19 00:45:35 2009
From: akb+lists.netrek-dev at mirror.to (Andrew K. Bressen)
Date: Tue, 19 May 2009 01:45:35 -0400
Subject: [netrek-dev] Netrek Game On! memory usage issue
In-Reply-To: <ecfa260c0905180730j1c80bec4q9ac4da0fecb20394@mail.gmail.com>
	(Zachary Uram's message of "Mon, 18 May 2009 10:30:30 -0400")
References: <ecfa260c0905180730j1c80bec4q9ac4da0fecb20394@mail.gmail.com>
Message-ID: <0q3ab1zlvk.fsf@mirror.to>


Under Linux on my system, it's only (!) using 20 MB of RAM... BUT... 
it is occupying 215 MB of virtual memory. I assume this is due to the
java virtual machine being a total pig; the only other java app I have
handy is a music player which takes even more memory.

  --akb



From jrd at gerdesas.com  Tue May 19 01:08:38 2009
From: jrd at gerdesas.com (John R. Dennison)
Date: Tue, 19 May 2009 01:08:38 -0500
Subject: [netrek-dev] Netrek Game On! memory usage issue
In-Reply-To: <0q3ab1zlvk.fsf@mirror.to>
References: <ecfa260c0905180730j1c80bec4q9ac4da0fecb20394@mail.gmail.com>
	<0q3ab1zlvk.fsf@mirror.to>
Message-ID: <20090519060836.GE28528@frodo.gerdesas.com>

On Tue, May 19, 2009 at 01:45:35AM -0400, Andrew K. Bressen wrote:
> 
> Under Linux on my system, it's only (!) using 20 MB of RAM... BUT... 
> it is occupying 215 MB of virtual memory. I assume this is due to the
> java virtual machine being a total pig; the only other java app I have
> handy is a music player which takes even more memory.

	That's absolutely ridiculous.





							John

-- 
"I'm sorry but our engineers do not have phones."
As stated by a Network Solutions Customer Service representative when asked to
be put through to an engineer.

"My other computer is your windows box."
                                     Ralf Hildebrandt
<sxem> trying to play sturgeon while it's under attack is apparently not fun.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20090519/d6fda538/attachment.pgp 

From mark at mark.mielke.cc  Tue May 19 10:57:14 2009
From: mark at mark.mielke.cc (Mark Mielke)
Date: Tue, 19 May 2009 11:57:14 -0400
Subject: [netrek-dev] Netrek Game On! memory usage issue
In-Reply-To: <20090519060836.GE28528@frodo.gerdesas.com>
References: <ecfa260c0905180730j1c80bec4q9ac4da0fecb20394@mail.gmail.com>	<0q3ab1zlvk.fsf@mirror.to>
	<20090519060836.GE28528@frodo.gerdesas.com>
Message-ID: <4A12D6DA.5020404@mark.mielke.cc>

John R. Dennison wrote:
> On Tue, May 19, 2009 at 01:45:35AM -0400, Andrew K. Bressen wrote:
>   
>> Under Linux on my system, it's only (!) using 20 MB of RAM... BUT... 
>> it is occupying 215 MB of virtual memory. I assume this is due to the
>> java virtual machine being a total pig; the only other java app I have
>> handy is a music player which takes even more memory.
>>     
>
> 	That's absolutely ridiculous.
>   

One thing to note about "Hello World!" in Java, is that it requires 
*all* of the base systems to be loaded to execute. This includes the JIT 
compiler, the garbage collector (which pre-allocates just in case!), the 
base libraries (most of Java is *written* in Java - *including* classes 
like String), and the I/O libraries. These libraries are stored in 
portable format (.jar of .class files) and the JIT compiler will compile 
these from portable byte code to native instructions based on runtime 
profiling.

Java wasn't meant to show off "Hello World." Hello World is a useless 
program. It provides no value. The ability for a language to print 
"Hello World" with minimal memory requirements does show off a certain 
benefit, but perhaps at the expense of others. The tiniest "Hello World" 
program is probably written in assembler or machine code with no support 
libraries to handle scaling to support larger applications. Some might 
consider writing a program such as Netrek in assembler as ridiculous. 
Some might enjoy the challenge! :-)

Ridiculous? It depends on the goal. :-)

Cheers,
mark

-- 
Mark Mielke <mark at mielke.cc>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20090519/578ef7e1/attachment.htm 

From Douglas.Gremaux at Navistar.com  Tue May 19 07:53:04 2009
From: Douglas.Gremaux at Navistar.com (Gremaux, Douglas A)
Date: Tue, 19 May 2009 07:53:04 -0500
Subject: [netrek-dev] Bug: Peace scum planet take, bronco vanilla server
Message-ID: <089163D0929CFA4EA9611E1BC86D9753A177B6C4@BRKSVW125.ad.navistar.com>

All,

Observed on pickled server last night during pre-T entertainment.  Did not try it during t-mode.  While peaced and carrying, fly to enemy planet, orbit with shields up, and beam down.  Shields drop but armies don't, which is expected.  Declare war.  Armies start dropping immediately before war declaration 10 second timer runs out.  I believe this is a bug.  Note that beam down key was only pressed before declaring war. Client XP 2009 although I doubt that matters.  Bug is repeatable.

Tried same technique with bombing.  Shields stayed up.  Bombing never started even after war declaration timer ran out, which is expected.

Doug Gremaux
aka He'sDeadJim


________________________________
Disclaimer Confidentiality Notice: This e-mail, and any attachments
and/or documents linked to this email, are intended for the
addressee and may contain information that is privileged,
confidential, proprietary, or otherwise protected by law. Any
dissemination, distribution, or copying is prohibited. This
notice serves as a confidentiality marking for the purpose of
any confidentiality or nondisclosure agreement. If you have
received this communication in error, please contact the
original sender.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20090519/306955fa/attachment.htm 

From jeremy.shupe at gmail.com  Tue May 19 09:49:36 2009
From: jeremy.shupe at gmail.com (Jeremy Shupe)
Date: Tue, 19 May 2009 08:49:36 -0600
Subject: [netrek-dev] Netrek Game On! memory usage issue
In-Reply-To: <20090518233628.GD17572@us.netrek.org>
References: <ecfa260c0905180730j1c80bec4q9ac4da0fecb20394@mail.gmail.com>
	<20090518233628.GD17572@us.netrek.org>
Message-ID: <475567520905190749v1caa6da3wc4d7ea0026e8f48f@mail.gmail.com>

The ss was taken after the program had been running for about an hour.  I've
looked at it after it has been running for several hours and noticed a small
uptick in the memory useage.  Zach told me that there are peeps complaining
that it was taking up to 300 mb.  I looked over the code, and cannot
understand that assertion.  There are, however,  things I could do to make
the code more efficient, such as variable reuse, assuming that the compiler
isn't doing that already.

Admittedly; most Java programmers have gotten lazy as we rely on the
compiler to much.

Another thing that I can do to minimize the memory footprint is not pre-load
the audio clip objects.  I actually have 2 sound engines, one for small
apps, such as this, that pre loads the audio clips into memory and calls
them as needed.  The other engine maintains a cache, it checks the cache
and plays the clip if it finds it there, if not, it creates the file, plays
it, and inserts it into the cache.
This means that only files that are being used are loaded into memory.  This
frees up memory in exchange for runtime response.  As an added feature the
engine also tries to "garbage collect" the cache by routinely investigating
how long it has been since each loaded file has been used, and deleting the
ones that haven't since the last sweep.

In this case, where the program is only playing a clip every 60 seconds, at
maximum, runtime response is not a factor.

All told, however, I can not understand how the program might have swelled
to 300 megs of memory usage.  I am trying to do a methodical analysis today,
tracking memory usage over time.  So I'll look at those results tonight.

I can not log onto the newsgroup from here ($@%$#@!$% web nanny, I seriously
need to set up a vpn tunnel to my home machine, but then again, even with
the nanny I do blow lots of time on "stuff", like this email) but I am
preparing a post to the iPhone thread:  Let me know what you think.

I had similar thoughts when Microsoft allowed ordinary hacks to program
games for the xbox.  (Netrek on the xbox, COOL!!)  Peeps in this thread are
assuming a full client, although there has been mention of a stand alone
single player version.  My thoughts on this subject are this:
1.  The single player version is the best option.  Everybody is assuming a
full blown client.  That opens a huge can of worms.  There are issues
involved such as airtime (You don't think the cell companies are going to
let iPhone users play Netrek without charging for something, bandwidth,
airtime, oxygen, ... do you?).  Play balance, a cell phone user will get
their asses handed to them, get frustrated and regret not spending that $1
that they paid for the app on a McDonald's cherry pie,  etc.

If, however, we created a scaled down single player version, say a universe
with a total of 10 planets, for example 5 Ori, and 5 Fed, then there are
allot of possibilities.  Messaging would be dead and the galactic map could
take the space used by the messaging and player windows.

The point behind this version, would be to get people interested in Netrek,
and to get them some sort of practical training.  All the time that they are
playing, or maybe at launch and closing, we would be sending messages such
as "If you like this, go download and play the full game, for free, at
blah"  A portion of the peeps would go home, download the game, and join the
community.  If that was even 1/2 of 1% of iPhone users that would still be a
huge increase of new blood.

In short, I am taking the middle road between the opinions issued here.
That yes, a iPhone, or handheld version of the game is appropriate, but that
that version should not be a full blown client, and should be used primarily
as a recuiting and training tool.

2. Now we are talking $$$.  Money make people crazy.  What must be stated
clearly BEFORE work begins on such a project is who gets the proceeds, and
how those proceeds will be spent.  I don't know who developed the code
base.  My assumption is that the number of contributors is at least several
score, if not over a hundred.  Before anyone proceeds on such a venture they
need to be covered to ensure that those individuals are not going to sue for
a cut of the pie.


Finally, I am not on the developer email list, and would like to be added.
primary email:  coljlc1863 at hotmail.com
secondary email: jeremy.shupe at gmail.com

Thanx
Jeremy

On Mon, May 18, 2009 at 5:36 PM, James Cameron <quozl at us.netrek.org> wrote:

> On Mon, May 18, 2009 at 10:30:30AM -0400, Zachary Uram wrote:
> > Someone in IRC (I think it was Bob Tanner) mentioned that running the
> > poller application under OS X was eating up over 300MB of system
> > memory.
>
> Bob, take a look at OS X's Java VM for a hello world.  Exclude cache.
>
> > I talked to Jeremy and he said this should not be happening
> > and that there should not be any memory leaks in his app.
>
> Good.
>
> > Here is a
> > screenshot he sent me (he is running MS Windows Vista I think) showing
> > only 19MB of memory being used:
> >
> > http://www.jesujuva.org/mem-usage.jpg
>
> Irrelevant.  It is the trend that is important.  Measure the usage at
> hourly intervals.  Or if this was taken after some hours say so.
>
> I wouldn't be surprised to find it is a feature of the virtual machine
> in use.  Zach, why don't you load up a Java VM yourself and test it out,
> that way we'd get the Linux data point.
>
> As another data point, the metaget program that I use takes a peak of
> 2Mb virtual memory, 644Kb physical memory, and is 13k on disk.  The
> large difference between the on-disk size and the peak virtual memory
> size is caused by the very large C run time library.
>
> Jeremy, are you on the netrek-dev mailing list yet?
>
> --
> James Cameron    mailto:quozl at us.netrek.org     http://quozl.netrek.org/
>



-- 
Just because you are paranoid, doesn't mean the world isn't out to get you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20090519/42064f77/attachment.htm 

From chris.lukassen at gmail.com  Tue May 19 12:54:12 2009
From: chris.lukassen at gmail.com (Chris Lukassen)
Date: Tue, 19 May 2009 19:54:12 +0200
Subject: [netrek-dev] iPhone MacTrek
In-Reply-To: <mailman.1561.1242676994.2376.netrek-dev@us.netrek.org>
References: <mailman.1561.1242676994.2376.netrek-dev@us.netrek.org>
Message-ID: <D732CE8D-6254-47E2-9886-308F34E06334@gmail.com>

> Hi

I did some testing already, it's doable, but still a huge effort the  
API is quite different, and the GUI useless

> An iPhone Netrek client would quickly add at least thousands of
> players, not to mention whomever wrote it would very likely get rich
> quick even if you sold a $0.99 version :)

Hehehe.. there;s an incentive though you will run into problems with  
the licence

> As it seems the Mac client is already written in Objective C that's
> probably a huge jump start. What license is that code under? I suppose
> you could still sell it if it's GPL, you'd just have to release the
> source.

No you can't, but you could charge packaging/service cost as e.g.  
SuSE, Redhat etc. does

> Ideas (please add your own)
> * stand alone mode so you don't need a network or server necessarily

Not my top prio :-) but it would not be too difficult
>
> * touch and drag your ship ( a vector indicating speed would appear)

good idea, i was thinking about tilting the phone, left/right top/ 
bottem=speed
>
> * tap to fire torpedos
> * tap with two fingers for phaser

the latter would never be accurate, you could consider some logic,  
which based on distance switches automatically to phasers, alas that  
would be rather borgish.
>
> * pull three fingers straight down for repair mode
> * twist two fingers clock wise for shields up
> * twist two fingers counter clockwise for shields down

i've not figured out how to get those events (yet) but i like the idea

> * just like photos of course two fingers squeezing out would be zoom
> in - opposite zoom out
> * you can swipe to flick between galaxy overview and close in view
>
ticking a planet means lock? (and when carrign send the carry message  
automatically)

> * the only thing that's not obvious is how to communicate, but you
> could have the canned messages easily enough - 'transporting 4 armies
> to earth'

text to voice for incomming messages is very nasty, scrolling a few  
lines takes to many pixels, recode the strings or RCM to sounds or led  
like controls is hard and unfriendly.

You could think of runnning a dedicated server just for iphone  
clients, which allows people to play with other clients or not, i  
agree with John that the game would be unbalanced with different  
clients, but it may not be a bad thing. Let the first version be  
called "MacTrek Scout Bomber" and limit the ship choice, that reduces  
a lot functions they may need, allows for an unbalanced client and  
offers an upgrade path.

I think there are a number of scenarios:

1.) dedicated server (hence every one has the same limitations, but  
users may move over to Netrek over time)
2.) mixed server with limited iphone clients
3.) mixed server with different iphone clients, these clients  
compensate their lack of features with some "borg"  features. It will  
be hard to create balance with this road, and controversial in the  
Netrek community.

2ct

Chris




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20090519/9b2ea26c/attachment-0001.htm 

From billbalcerski at gmail.com  Tue May 19 13:09:52 2009
From: billbalcerski at gmail.com (Bill Balcerski)
Date: Tue, 19 May 2009 14:09:52 -0400
Subject: [netrek-dev] Bug: Peace scum planet take, bronco vanilla server
In-Reply-To: <089163D0929CFA4EA9611E1BC86D9753A177B6C4@BRKSVW125.ad.navistar.com>
References: <089163D0929CFA4EA9611E1BC86D9753A177B6C4@BRKSVW125.ad.navistar.com>
Message-ID: <45ab86180905191109l29eae239ydf1eb6fd6012d105@mail.gmail.com>

This is a feature.  Maybe it started as a bug, but it's been known
since at least 1992 (check rec.games.netrek and search for declare
war).  Consider your netrek_trick_knowledge++.


On Tue, May 19, 2009 at 8:53 AM, Gremaux, Douglas A
<Douglas.Gremaux at navistar.com> wrote:
> Observed on pickled server last night during pre-T entertainment.  Did not
> try it during t-mode.  While peaced and carrying, fly to enemy planet, orbit
> with shields up, and beam down.  Shields drop but armies don't, which is
> expected.  Declare war.  Armies start dropping immediately before war
> declaration 10 second timer runs out.


From basic at us.netrek.org  Tue May 19 15:07:41 2009
From: basic at us.netrek.org (Bob Tanner)
Date: Tue, 19 May 2009 15:07:41 -0500
Subject: [netrek-dev] Netrek Game On! memory usage issue
References: <ecfa260c0905180730j1c80bec4q9ac4da0fecb20394@mail.gmail.com>
	<20090518233628.GD17572@us.netrek.org>
	<475567520905190749v1caa6da3wc4d7ea0026e8f48f@mail.gmail.com>
Message-ID: <guv3id$1ba$1@ger.gmane.org>

On 2009-05-19 09:49:36 -0500, Jeremy Shupe 
<jeremy.shupe at gmail.com> said:

> All told, however, I can not understand how the program might have swelled
> to 300 megs of memory usage.  I am trying to do a methodical analysis today,
> tracking memory usage over time.  So I'll look at those results tonight.

Lots of details missing from my irc discussion. :-)

I never said the program (poller) leaked memory or there was anything 
wrong with the poller.

I just stated that the JVM when running the poller takes 300M. I 
further stated that I think the Swing to Cocoa bridge is what is the 
memory pig (not the poller).

I have not done any testing. As far as I know 300M is the base memory 
footprint for the JVM under osx.

-- 
Bob Tanner <basic at us.netrek.org>          
Key fingerprint = F785 DDFC CF94 7CE8 AA87 3A9D 3895 26F1 0DDB E378




From niclas at acc.umu.se  Tue May 19 15:26:43 2009
From: niclas at acc.umu.se (Niclas Fredriksson)
Date: Tue, 19 May 2009 22:26:43 +0200 (MEST)
Subject: [netrek-dev] Bug: Peace scum planet take, bronco vanilla server
In-Reply-To: <089163D0929CFA4EA9611E1BC86D9753A177B6C4@BRKSVW125.ad.navistar.com>
References: <089163D0929CFA4EA9611E1BC86D9753A177B6C4@BRKSVW125.ad.navistar.com>
Message-ID: <Pine.GSO.4.64.0905192226300.26948@shaka.acc.umu.se>

On Tue, 19 May 2009, Gremaux, Douglas A wrote:

> Observed on pickled server last night during pre-T entertainment.  Did 
> not try it during t-mode.  While peaced and carrying, fly to enemy 
> planet, orbit with shields up, and beam down.  Shields drop but armies 
> don't, which is expected.  Declare war.  Armies start dropping 
> immediately before war declaration 10 second timer runs out.  I believe 
> this is a bug.  Note that beam down key was only pressed before 
> declaring war. Client XP 2009 although I doubt that matters.  Bug is 
> repeatable.

Working as intended.

-- 
Niclas


From jrd at gerdesas.com  Tue May 19 16:51:08 2009
From: jrd at gerdesas.com (John R. Dennison)
Date: Tue, 19 May 2009 16:51:08 -0500
Subject: [netrek-dev] Bug: Peace scum planet take, bronco vanilla server
In-Reply-To: <Pine.GSO.4.64.0905192226300.26948@shaka.acc.umu.se>
References: <089163D0929CFA4EA9611E1BC86D9753A177B6C4@BRKSVW125.ad.navistar.com>
	<Pine.GSO.4.64.0905192226300.26948@shaka.acc.umu.se>
Message-ID: <20090519215108.GH28528@frodo.gerdesas.com>

On Tue, May 19, 2009 at 10:26:43PM +0200, Niclas Fredriksson wrote:
> On Tue, 19 May 2009, Gremaux, Douglas A wrote:
> 
> > Observed on pickled server last night during pre-T entertainment.  Did 
> > not try it during t-mode.  While peaced and carrying, fly to enemy 
> > planet, orbit with shields up, and beam down.  Shields drop but armies 
> > don't, which is expected.  Declare war.  Armies start dropping 
> > immediately before war declaration 10 second timer runs out.  I believe 
> > this is a bug.  Note that beam down key was only pressed before 
> > declaring war. Client XP 2009 although I doubt that matters.  Bug is 
> > repeatable.
> 
> Working as intended.

	Working, yes.  Intended, I doubt that.  It bears every
	indication of a design flaw as does the legacy base refit 
	conditions.  

	Please note, I am not advocating changing it from the way
	it currently operates.  I would, however, suggest documenting
	this behavior somewhere as it's not how one would expect it
	to function.





							John

-- 
"I'm sorry but our engineers do not have phones."
As stated by a Network Solutions Customer Service representative when asked to
be put through to an engineer.

"My other computer is your windows box."
                                     Ralf Hildebrandt
<sxem> trying to play sturgeon while it's under attack is apparently not fun.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20090519/f81d1cbf/attachment.pgp 

From quozl at us.netrek.org  Tue May 19 19:38:23 2009
From: quozl at us.netrek.org (James Cameron)
Date: Wed, 20 May 2009 10:38:23 +1000
Subject: [netrek-dev] Bug: Peace scum planet take, bronco vanilla server
In-Reply-To: <20090519215108.GH28528@frodo.gerdesas.com>
References: <089163D0929CFA4EA9611E1BC86D9753A177B6C4@BRKSVW125.ad.navistar.com>
	<Pine.GSO.4.64.0905192226300.26948@shaka.acc.umu.se>
	<20090519215108.GH28528@frodo.gerdesas.com>
Message-ID: <20090520003823.GL8293@us.netrek.org>

On Tue, May 19, 2009 at 04:51:08PM -0500, John R. Dennison wrote:
> 	Working, yes.  Intended, I doubt that.  It bears every
> 	indication of a design flaw as does the legacy base refit 
> 	conditions.  

Yes, probably a design flaw, but I'm not going to change it, because it
is too well known.

It was present in 2.7pl5 released in early 1997.  Not sure when the
change actually turned up, but it is in interface.c where the Pearl
Harbor (sic) message resides:

    if (!(me->p_war & owner)) {
        new_warning(41,"Must declare war first (no Pearl Harbor syndrome
allowed here).");
	return;
    }

There was no mention of this code being added in the CHANGES file, which
takes us back to 1993.

Prior to that code being added, the ntserv would set PFBOMB and the
daemon would ignore it until war was declared:

    /* do bombing */
    if ((!(j->p_flags & PFORBIT)) || (!(j->p_flags & PFBOMB)))
      continue;
    l = &planets[j->p_planet];

    if (j->p_team == l->pl_owner)
      continue;
    if (!(j->p_war & l->pl_owner))
      continue;
    if (l->pl_armies < 5)
      continue;

So without that added code, the effect would have been the same.

> 	Please note, I am not advocating changing it from the way
> 	it currently operates.  I would, however, suggest documenting
> 	this behavior somewhere as it's not how one would expect it
> 	to function.

Where would we document it and why?

Client xtrekrc options could be renamed "CHEAT CODES" to better appeal
to the newer community, perhaps this feature could be labelled a "CHEAT"
even though it is intentional.

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


From jrd at gerdesas.com  Tue May 19 21:05:56 2009
From: jrd at gerdesas.com (John R. Dennison)
Date: Tue, 19 May 2009 21:05:56 -0500
Subject: [netrek-dev] Bug: Peace scum planet take, bronco vanilla server
In-Reply-To: <20090520003823.GL8293@us.netrek.org>
References: <089163D0929CFA4EA9611E1BC86D9753A177B6C4@BRKSVW125.ad.navistar.com>
	<Pine.GSO.4.64.0905192226300.26948@shaka.acc.umu.se>
	<20090519215108.GH28528@frodo.gerdesas.com>
	<20090520003823.GL8293@us.netrek.org>
Message-ID: <20090520020556.GI28528@frodo.gerdesas.com>

On Wed, May 20, 2009 at 10:38:23AM +1000, James Cameron wrote:
> 
> Where would we document it and why?

	Wiki is a fine place.  We can put up a "clue tricks" page.

	And it needs to be documented because it goes against
	expectations of how it operates.  Unless there is something
	I am missing (which is always possible) nothing else works quite
	like dropping and peacing.





							John

-- 
"I'm sorry but our engineers do not have phones."
As stated by a Network Solutions Customer Service representative when asked to
be put through to an engineer.

"My other computer is your windows box."
                                     Ralf Hildebrandt
<sxem> trying to play sturgeon while it's under attack is apparently not fun.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20090519/425e6696/attachment.pgp 

From quozl at us.netrek.org  Tue May 19 22:49:52 2009
From: quozl at us.netrek.org (James Cameron)
Date: Wed, 20 May 2009 13:49:52 +1000
Subject: [netrek-dev] Bug: Peace scum planet take, bronco vanilla server
In-Reply-To: <20090520020556.GI28528@frodo.gerdesas.com>
References: <089163D0929CFA4EA9611E1BC86D9753A177B6C4@BRKSVW125.ad.navistar.com>
	<Pine.GSO.4.64.0905192226300.26948@shaka.acc.umu.se>
	<20090519215108.GH28528@frodo.gerdesas.com>
	<20090520003823.GL8293@us.netrek.org>
	<20090520020556.GI28528@frodo.gerdesas.com>
Message-ID: <20090520034952.GQ8293@us.netrek.org>

On Tue, May 19, 2009 at 09:05:56PM -0500, John R. Dennison wrote:
> On Wed, May 20, 2009 at 10:38:23AM +1000, James Cameron wrote:
> > Where would we document it and why?
> 
> 	Wiki is a fine place.  We can put up a "clue tricks" page.

I think that name sucks.  We need to get with the new wording ... CHEAT
CODES.

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


From netrek at gmail.com  Tue May 19 23:37:00 2009
From: netrek at gmail.com (Zachary Uram)
Date: Wed, 20 May 2009 00:37:00 -0400
Subject: [netrek-dev] Bug: Peace scum planet take, bronco vanilla server
In-Reply-To: <20090520034952.GQ8293@us.netrek.org>
References: <089163D0929CFA4EA9611E1BC86D9753A177B6C4@BRKSVW125.ad.navistar.com>
	<Pine.GSO.4.64.0905192226300.26948@shaka.acc.umu.se>
	<20090519215108.GH28528@frodo.gerdesas.com>
	<20090520003823.GL8293@us.netrek.org>
	<20090520020556.GI28528@frodo.gerdesas.com>
	<20090520034952.GQ8293@us.netrek.org>
Message-ID: <ecfa260c0905192137mc724b04s41e3e424386dc134@mail.gmail.com>

On Tue, May 19, 2009 at 11:49 PM, James Cameron
>
> I think that name sucks.  We need to get with the new wording ... CHEAT
> CODES.

I agree with James on this. Most sites gamers refer to for info that
gives them an advantage is referenced as "cheat codes". Google will
confirm this.

Zach


From quozl at us.netrek.org  Tue May 19 23:46:57 2009
From: quozl at us.netrek.org (James Cameron)
Date: Wed, 20 May 2009 14:46:57 +1000
Subject: [netrek-dev] Bug: Peace scum planet take, bronco vanilla server
In-Reply-To: <ecfa260c0905192137mc724b04s41e3e424386dc134@mail.gmail.com>
References: <089163D0929CFA4EA9611E1BC86D9753A177B6C4@BRKSVW125.ad.navistar.com>
	<Pine.GSO.4.64.0905192226300.26948@shaka.acc.umu.se>
	<20090519215108.GH28528@frodo.gerdesas.com>
	<20090520003823.GL8293@us.netrek.org>
	<20090520020556.GI28528@frodo.gerdesas.com>
	<20090520034952.GQ8293@us.netrek.org>
	<ecfa260c0905192137mc724b04s41e3e424386dc134@mail.gmail.com>
Message-ID: <20090520044657.GS8293@us.netrek.org>

On Wed, May 20, 2009 at 12:37:00AM -0400, Zachary Uram wrote:
> I agree with James on this. Most sites gamers refer to for info that
> gives them an advantage is referenced as "cheat codes". Google will
> confirm this.

And *we* refer to it as documentation, but we're old fogies.

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


From jrd at gerdesas.com  Tue May 19 23:53:51 2009
From: jrd at gerdesas.com (John R. Dennison)
Date: Tue, 19 May 2009 23:53:51 -0500
Subject: [netrek-dev] Bug: Peace scum planet take, bronco vanilla server
In-Reply-To: <20090520044657.GS8293@us.netrek.org>
References: <089163D0929CFA4EA9611E1BC86D9753A177B6C4@BRKSVW125.ad.navistar.com>
	<Pine.GSO.4.64.0905192226300.26948@shaka.acc.umu.se>
	<20090519215108.GH28528@frodo.gerdesas.com>
	<20090520003823.GL8293@us.netrek.org>
	<20090520020556.GI28528@frodo.gerdesas.com>
	<20090520034952.GQ8293@us.netrek.org>
	<ecfa260c0905192137mc724b04s41e3e424386dc134@mail.gmail.com>
	<20090520044657.GS8293@us.netrek.org>
Message-ID: <20090520045350.GN28528@frodo.gerdesas.com>

On Wed, May 20, 2009 at 02:46:57PM +1000, James Cameron wrote:
> 
> And *we* refer to it as documentation, but we're old fogies.

	Frankly the page / section is called is irrelevant; as
	long as the tricks like the one under discussion are
	actually documented.




							John

-- 
"I'm sorry but our engineers do not have phones."
As stated by a Network Solutions Customer Service representative when asked to
be put through to an engineer.

"My other computer is your windows box."
                                     Ralf Hildebrandt
<sxem> trying to play sturgeon while it's under attack is apparently not fun.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20090519/a3000862/attachment-0001.pgp 

From niclas at acc.umu.se  Wed May 20 03:48:19 2009
From: niclas at acc.umu.se (Niclas Fredriksson)
Date: Wed, 20 May 2009 10:48:19 +0200 (MEST)
Subject: [netrek-dev] Bug: Peace scum planet take, bronco vanilla server
In-Reply-To: <20090519215108.GH28528@frodo.gerdesas.com>
References: <089163D0929CFA4EA9611E1BC86D9753A177B6C4@BRKSVW125.ad.navistar.com>
	<Pine.GSO.4.64.0905192226300.26948@shaka.acc.umu.se>
	<20090519215108.GH28528@frodo.gerdesas.com>
Message-ID: <Pine.GSO.4.64.0905201042020.3475@shaka.acc.umu.se>

On Tue, 19 May 2009, John R. Dennison wrote:

> On Tue, May 19, 2009 at 10:26:43PM +0200, Niclas Fredriksson wrote:
>> On Tue, 19 May 2009, Gremaux, Douglas A wrote:
>>
>>> Observed on pickled server last night during pre-T entertainment.  Did
>>> not try it during t-mode.  While peaced and carrying, fly to enemy
>>> planet, orbit with shields up, and beam down.  Shields drop but armies
>>> don't, which is expected.  Declare war.  Armies start dropping
>>> immediately before war declaration 10 second timer runs out.  I believe
>>> this is a bug.  Note that beam down key was only pressed before
>>> declaring war. Client XP 2009 although I doubt that matters.  Bug is
>>> repeatable.
>>
>> Working as intended.
>
> 	Working, yes.  Intended, I doubt that.

Working as intended the way the tea bag, the slinky, Coke and USA are 
working as intended.

Well, maybe USA is a bad example.

-- 
Niclas

PS This mailinglist should be reconfigured to have the list address as 
reply-to.


From jrd at gerdesas.com  Wed May 20 04:00:37 2009
From: jrd at gerdesas.com (John R. Dennison)
Date: Wed, 20 May 2009 04:00:37 -0500
Subject: [netrek-dev] Bug: Peace scum planet take, bronco vanilla server
In-Reply-To: <Pine.GSO.4.64.0905201042020.3475@shaka.acc.umu.se>
References: <089163D0929CFA4EA9611E1BC86D9753A177B6C4@BRKSVW125.ad.navistar.com>
	<Pine.GSO.4.64.0905192226300.26948@shaka.acc.umu.se>
	<20090519215108.GH28528@frodo.gerdesas.com>
	<Pine.GSO.4.64.0905201042020.3475@shaka.acc.umu.se>
Message-ID: <20090520090037.GQ28528@frodo.gerdesas.com>

On Wed, May 20, 2009 at 10:48:19AM +0200, Niclas Fredriksson wrote:
> 
> Working as intended the way the tea bag, the slinky, Coke and USA are 
> working as intended.
> 
> Well, maybe USA is a bad example.

	Now now, be nice.

> PS This mailinglist should be reconfigured to have the list address as 
> reply-to.

	Seconded.  James can you please fix this?




							John

-- 
"I'm sorry but our engineers do not have phones."
As stated by a Network Solutions Customer Service representative when asked to
be put through to an engineer.

"My other computer is your windows box."
                                     Ralf Hildebrandt
<sxem> trying to play sturgeon while it's under attack is apparently not fun.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20090520/429714d3/attachment.pgp 

From coljlc1863 at hotmail.com  Wed May 20 09:43:50 2009
From: coljlc1863 at hotmail.com (J C)
Date: Wed, 20 May 2009 08:43:50 -0600
Subject: [netrek-dev] Netrek Game On! memory usage issue
In-Reply-To: <mailman.1613.1242795321.2376.netrek-dev@us.netrek.org>
References: <mailman.1613.1242795321.2376.netrek-dev@us.netrek.org>
Message-ID: <BLU124-W7AECC6076502C3C193828C6580@phx.gbl>


Heh.  Java is a memory pig.  That, however, is the nature of the beast.  Sun effectively sacrificed memory for portability.  As average system memory increases, that decision (as long as they can hold the jvm size stable) looks smarter and smarter.

 

At this point I've run the poller for 24 hours.  It is slowly increasing in size.  About an extra 150 KB per hour on average.  Personally, I find this extremely irritating.  I am guessing that over time I have gotten complacent about variable useage.  The basic assumption at this point among Java programers is that the compiler will deal with efficiency.  For the most part this is true.  This is an object lesson for me to not rely soley on the compiler for effeciancy.

 

My next patch will focus on minimizing the memory footprint.  I am going to comb through the code, and look for ways to reduce variable instantiation.  I am going to not load the audio clips into memory, but instantiate them when needed.

 

Since the game works in UDP I think that the ideal of making the poller work in TCP/IP, as a back up to the UDP code, is dumb.  So I was also considering deleting that code.  That will mean fewer variables and an overall simpler, easier to maintain, program.
 

Suggestions?

 

> Message: 2
> Date: Tue, 19 May 2009 15:07:41 -0500
> From: Bob Tanner <basic at us.netrek.org>
> Subject: Re: [netrek-dev] Netrek Game On! memory usage issue
> To: netrek-dev at us.netrek.org
> Message-ID: <guv3id$1ba$1 at ger.gmane.org>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> On 2009-05-19 09:49:36 -0500, Jeremy Shupe 
> <jeremy.shupe at gmail.com> said:
> 
> > All told, however, I can not understand how the program might have swelled
> > to 300 megs of memory usage. I am trying to do a methodical analysis today,
> > tracking memory usage over time. So I'll look at those results tonight.
> 
> Lots of details missing from my irc discussion. :-)
> 
> I never said the program (poller) leaked memory or there was anything 
> wrong with the poller.
> 
> I just stated that the JVM when running the poller takes 300M. I 
> further stated that I think the Swing to Cocoa bridge is what is the 
> memory pig (not the poller).
> 
> I have not done any testing. As far as I know 300M is the base memory 
> footprint for the JVM under osx.

_________________________________________________________________
Hotmail? goes with you. 
http://windowslive.com/Tutorial/Hotmail/Mobile?ocid=TXT_TAGLM_WL_HM_Tutorial_Mobile1_052009
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20090520/bc6f3c0c/attachment.htm 

From billbalcerski at gmail.com  Wed May 20 10:09:46 2009
From: billbalcerski at gmail.com (Bill Balcerski)
Date: Wed, 20 May 2009 11:09:46 -0400
Subject: [netrek-dev] Netrek Game On! memory usage issue
In-Reply-To: <BLU124-W7AECC6076502C3C193828C6580@phx.gbl>
References: <mailman.1613.1242795321.2376.netrek-dev@us.netrek.org>
	<BLU124-W7AECC6076502C3C193828C6580@phx.gbl>
Message-ID: <45ab86180905200809r6cc2e49x6c0a5944f1b9de1b@mail.gmail.com>

On Wed, May 20, 2009 at 10:43 AM, J C <coljlc1863 at hotmail.com> wrote:
> Since the game works in UDP I think that the ideal of making the poller work
> in TCP/IP, as a back up to the UDP code, is dumb.  So I was also considering
> deleting that code.
>
Sounds like a good idea.


From jrd at gerdesas.com  Wed May 20 12:26:48 2009
From: jrd at gerdesas.com (John R. Dennison)
Date: Wed, 20 May 2009 12:26:48 -0500
Subject: [netrek-dev] Netrek Game On! memory usage issue
In-Reply-To: <BLU124-W7AECC6076502C3C193828C6580@phx.gbl>
References: <mailman.1613.1242795321.2376.netrek-dev@us.netrek.org>
	<BLU124-W7AECC6076502C3C193828C6580@phx.gbl>
Message-ID: <20090520172645.GR28528@frodo.gerdesas.com>

On Wed, May 20, 2009 at 08:43:50AM -0600, J C wrote:
> 
> Since the game works in UDP I think that the ideal of making the poller
> work in TCP/IP, as a back up to the UDP code, is dumb.  So I was also
> considering deleting that code.  That will mean fewer variables and an
> overall simpler, easier to maintain, program.

	Quick clarification:

	The game defaults to UDP for most data except messages, which
	are still TCP.  Game falls back to TCP if required.



							John


-- 
"I'm sorry but our engineers do not have phones."
As stated by a Network Solutions Customer Service representative when asked to
be put through to an engineer.

"My other computer is your windows box."
                                     Ralf Hildebrandt
<sxem> trying to play sturgeon while it's under attack is apparently not fun.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20090520/c6eba3ef/attachment.pgp 

From netrek at gmail.com  Wed May 20 14:34:59 2009
From: netrek at gmail.com (Zachary Uram)
Date: Wed, 20 May 2009 15:34:59 -0400
Subject: [netrek-dev] Netrek Game On! memory usage issue
In-Reply-To: <20090520172645.GR28528@frodo.gerdesas.com>
References: <mailman.1613.1242795321.2376.netrek-dev@us.netrek.org>
	<BLU124-W7AECC6076502C3C193828C6580@phx.gbl>
	<20090520172645.GR28528@frodo.gerdesas.com>
Message-ID: <ecfa260c0905201234v16f9cb87yc29df2df10f9c405@mail.gmail.com>

I vote for keeping the TCP fallback code. Some players for whatever
reason are forced into playing over TCP. I noticed this with asian
countries especially. Not fair to exclude them from using the poller
app.

Zach


From quozl at us.netrek.org  Wed May 20 18:02:19 2009
From: quozl at us.netrek.org (James Cameron)
Date: Thu, 21 May 2009 09:02:19 +1000
Subject: [netrek-dev] Bug: Peace scum planet take, bronco vanilla server
In-Reply-To: <20090520090037.GQ28528@frodo.gerdesas.com>
References: <089163D0929CFA4EA9611E1BC86D9753A177B6C4@BRKSVW125.ad.navistar.com>
	<Pine.GSO.4.64.0905192226300.26948@shaka.acc.umu.se>
	<20090519215108.GH28528@frodo.gerdesas.com>
	<Pine.GSO.4.64.0905201042020.3475@shaka.acc.umu.se>
	<20090520090037.GQ28528@frodo.gerdesas.com>
Message-ID: <20090520230219.GA14013@us.netrek.org>

On Wed, May 20, 2009 at 04:00:37AM -0500, John R. Dennison wrote:
> On Wed, May 20, 2009 at 10:48:19AM +0200, Niclas Fredriksson wrote:
> > PS This mailinglist should be reconfigured to have the list address as 
> > reply-to.
> 
> 	Seconded.  James can you please fix this?

Declined.  Code developers' mailing lists are like this for several
reasons which I won't go into.  Google for "reply-to considered harmful.

If you want a Netrek list that *does* have reply-to munging, use
netrek-forever.  Everyone here should be on that by now, unless you wish
to ignore your user base.

If your mail client hasn't got a "reply to all", then upgrade.  On mutt
the button is "g".

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


From quozl at us.netrek.org  Wed May 20 18:17:13 2009
From: quozl at us.netrek.org (James Cameron)
Date: Thu, 21 May 2009 09:17:13 +1000
Subject: [netrek-dev] Netrek Game On! memory usage issue
In-Reply-To: <ecfa260c0905201234v16f9cb87yc29df2df10f9c405@mail.gmail.com>
References: <mailman.1613.1242795321.2376.netrek-dev@us.netrek.org>
	<BLU124-W7AECC6076502C3C193828C6580@phx.gbl>
	<20090520172645.GR28528@frodo.gerdesas.com>
	<ecfa260c0905201234v16f9cb87yc29df2df10f9c405@mail.gmail.com>
Message-ID: <20090520231713.GD14013@us.netrek.org>

On Wed, May 20, 2009 at 03:34:59PM -0400, Zachary Uram wrote:
> I vote for keeping the TCP fallback code. Some players for whatever
> reason are forced into playing over TCP. I noticed this with asian
> countries especially. Not fair to exclude them from using the poller
> app.

Nobody was proposing to remove TCP from the game.

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


From quozl at us.netrek.org  Wed May 20 18:16:35 2009
From: quozl at us.netrek.org (James Cameron)
Date: Thu, 21 May 2009 09:16:35 +1000
Subject: [netrek-dev] Netrek Game On! memory usage issue
In-Reply-To: <BLU124-W7AECC6076502C3C193828C6580@phx.gbl>
References: <mailman.1613.1242795321.2376.netrek-dev@us.netrek.org>
	<BLU124-W7AECC6076502C3C193828C6580@phx.gbl>
Message-ID: <20090520231635.GC14013@us.netrek.org>

On Wed, May 20, 2009 at 08:43:50AM -0600, J C wrote:
> Since the game 

You mean metaserver.

> works in UDP I think that the ideal of making the poller work in
> TCP/IP, as a back up to the UDP code, is dumb.  So I was also
> considering deleting that code.  That will mean fewer variables and an
> overall simpler, easier to maintain, program.

I agree.  I'm planning to rip the TCP support out of COW.  It isn't
needed.  My netrek-client-pygame client never had it, never needed it.

I don't plan to remove TCP support from the metaserver, however.  It
clearly isn't in as much demand as the UDP support, so it won't get as
much focus in future.

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


From jrd at gerdesas.com  Wed May 20 19:32:52 2009
From: jrd at gerdesas.com (John R. Dennison)
Date: Wed, 20 May 2009 19:32:52 -0500
Subject: [netrek-dev] Bug: Peace scum planet take, bronco vanilla server
In-Reply-To: <20090520230219.GA14013@us.netrek.org>
References: <089163D0929CFA4EA9611E1BC86D9753A177B6C4@BRKSVW125.ad.navistar.com>
	<Pine.GSO.4.64.0905192226300.26948@shaka.acc.umu.se>
	<20090519215108.GH28528@frodo.gerdesas.com>
	<Pine.GSO.4.64.0905201042020.3475@shaka.acc.umu.se>
	<20090520090037.GQ28528@frodo.gerdesas.com>
	<20090520230219.GA14013@us.netrek.org>
Message-ID: <20090521003252.GS28528@frodo.gerdesas.com>

On Thu, May 21, 2009 at 09:02:19AM +1000, James Cameron wrote:
> 
> If your mail client hasn't got a "reply to all", then upgrade.  On mutt
> the button is "g".

	Ok.  I'll continue sending out copies to both the list and the
	poster for each and every reply I send, then.  My bandwidth
	is free :)




							John

-- 
"I'm sorry but our engineers do not have phones."
As stated by a Network Solutions Customer Service representative when asked to
be put through to an engineer.

"My other computer is your windows box."
                                     Ralf Hildebrandt
<sxem> trying to play sturgeon while it's under attack is apparently not fun.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20090520/798eac1d/attachment.pgp 

From jrd at gerdesas.com  Wed May 20 21:50:17 2009
From: jrd at gerdesas.com (John R. Dennison)
Date: Wed, 20 May 2009 21:50:17 -0500
Subject: [netrek-dev] [modemhero@users.sourceforge.net: [netrek-cvs]
	client/netrekxp/src data.c, 1.118, 1.119 defaults.c, 1.96,
	1.97 feature.c, 1.26, 1.27 input.c, 1.47, 1.48 option.c, 1.57, 1.58]
Message-ID: <20090521025016.GT28528@frodo.gerdesas.com>

Ok, seriously, this has gone far enough.  AutoPhaser?  Client ability to
override server FeaturePackets?

With the recent deprecation of RSA an admins ability of blocking clients
is limited without server changes; changes which a rogue client
developer can trivially bypass in any event.  

This type of crap with Bill has been going on for far too many years
now; this needs to be dealt with once and for all.  Feature packets
exist so admins can limit client abilities on their servers and present
an even playing field.  What makes Bill think he is above the law (per
sae) and has the ability of doing whatever it is he wants?






							John

----- Forwarded message from Bill Balcerski <modemhero at users.sourceforge.net> -----

> Date: Thu, 21 May 2009 02:37:31 +0000
> From: Bill Balcerski <modemhero at users.sourceforge.net>
> To: netrek-vanilla-cvs at lists.sourceforge.net,
> 	netrek-cvs at us.netrek.org
> Subject: [netrek-cvs] client/netrekxp/src data.c, 1.118, 1.119 defaults.c,
> 	1.96, 1.97 feature.c, 1.26, 1.27 input.c, 1.47, 1.48 option.c,
> 	1.57, 1.58
> 
> Update of /cvsroot/netrek/client/netrekxp/src
> In directory fdv4jf1.ch3.sourceforge.com:/tmp/cvs-serv13775/src
> 
> Modified Files:
> 	data.c defaults.c feature.c input.c option.c 
> Log Message:
> Added netrekrc option "useAllFeatures" to ignore server 
> settings for info/control feature packets.
> Added netrekrc option "autoPhaser" to phaser exact
> location of enemy target closest to cursor.  Works on
> local or map window.
> To do for autophaser:
> 1) Add sanity check to location (such as ship max
> phaser range).
> 2) Add support for phasering plasmas.
> 
> Index: input.c
> ===================================================================
> RCS file: /cvsroot/netrek/client/netrekxp/src/input.c,v
> retrieving revision 1.47
> retrieving revision 1.48
> diff -u -d -r1.47 -r1.48
> --- input.c	23 Jul 2008 10:09:34 -0000	1.47
> +++ input.c	21 May 2009 02:37:28 -0000	1.48
> @@ -54,6 +54,8 @@
>  struct obtype *target;
>  unsigned char key = ' ';
>  
> +void phaseraction (W_Event * data);
> +
>  /* this used to be 177 for an unknown reason...I think it may * have included
>   * various control characters.  We don't support * those anyway right?? - jn */
>  #define MAXKEY 224
> @@ -1697,8 +1699,7 @@
>      }
>      else if (data->key == W_MBUTTON)
>      {
> -        course = (unsigned char) (getcourse (data->Window, data->x, data->y));
> -        sendPhaserReq (course);
> +        phaseraction(data);
>      }
>      else if (data->key == W_XBUTTON1)
>      {
> @@ -1913,6 +1914,48 @@
>  }
>  
>  /******************************************************************************/
> +/***  phaseraction()                                                        ***/
> +/******************************************************************************/
> +void
> +phaseraction (W_Event * data)
> +{
> +    unsigned char course;
> +    int x, y;
> +    register struct player *j;
> +    struct obtype *gettarget (W_Window ww,
> +                              int x,
> +                              int y,
> +                              int targtype),
> +    *target;
> +
> +    if (autoPhaser) /* add range check here */ {
> +        target = gettarget (data->Window, data->x, data->y, TARG_ENEMY | TARG_CLOAK);
> +        if (target->o_num == -1) { /* failed to find a target */
> +            course = (unsigned char) (getcourse (data->Window, data->x, data->y));
> +            sendPhaserReq (course);
> +            return;
> +        }
> +        j = &players[target->o_num];
> +        if (data->Window == mapw)
> +        {
> +            x = j->p_x * GWINSIDE / GWIDTH;
> +            y = j->p_y * GWINSIDE / GWIDTH;
> +        }
> +        else
> +        {
> +            x = (j->p_x - me->p_x) / scaleFactor + TWINSIDE / 2;
> +            y = (j->p_y - me->p_y) / scaleFactor + TWINSIDE / 2;
> +        }
> +        /* Sanity check on x, y? Use ship max phaser range? */
> +        /* How about phasering plasma? */
> +        course = (unsigned char) (getcourse (data->Window, x, y));
> +    }
> +    else
> +        course = (unsigned char) (getcourse (data->Window, data->x, data->y));
> +    sendPhaserReq (course);
> +}
> +
> +/******************************************************************************/
>  /***  getcourse()                                                           ***/
>  /******************************************************************************/
>  int
> @@ -3333,19 +3376,13 @@
>  void
>  Key112 (W_Event * data)
>  {
> -    unsigned char course;
> -
>  #ifdef AUTOKEY
>      if (autoKey)
>          autoKeyPhaserReqOn ();
>      else
> -    {
> -        course = getcourse (data->Window, data->x, data->y);
> -        sendPhaserReq (course);
> -    }
> +        phaseraction(data);
>  #else
> -    course = (unsigned char) (getcourse (data->Window, data->x, data->y));
> -    sendPhaserReq (course);
> +    phaseraction (data);
>  #endif /* AUTOKEY */
>  
>  }
> 
> Index: defaults.c
> ===================================================================
> RCS file: /cvsroot/netrek/client/netrekxp/src/defaults.c,v
> retrieving revision 1.96
> retrieving revision 1.97
> diff -u -d -r1.96 -r1.97
> --- defaults.c	9 May 2009 21:21:43 -0000	1.96
> +++ defaults.c	21 May 2009 02:37:28 -0000	1.97
> @@ -43,6 +43,13 @@
>              NULL
>          }
>      },
> +    {"autoPhaser", &autoPhaser, RC_INT,
> +        {
> +            "Phaser exact location of enemy target closest to cursor",
> +            "Enemy must be within phaser range of your ship",
> +            NULL
> +        }
> +    },
>      {"autoQuit", &autoQuit, RC_INT,
>          {
>              "Autoquit timer (default 60)",
> @@ -907,6 +914,16 @@
>              NULL
>          }
>      },
> +    {"useAllFeatures", &useAllFeatures, RC_INT,
> +        {
> +            "Ignore server settings for info/control feature packets.",
> +            "This will automatically turn on motion mouse steering",
> +            "show army counts, show other's speed, show cloakers, turn",
> +            "keys, visibility range and beeplite regardless of what",
> +            "features the server requests that you turn off.",
> +            NULL
> +        }
> +    },
>      {"useCheckPlanets", &useCheckPlanets, RC_BOOL,
>          {
>              "Crosscheck with server to make sure all planet information is",
> 
> Index: data.c
> ===================================================================
> RCS file: /cvsroot/netrek/client/netrekxp/src/data.c,v
> retrieving revision 1.118
> retrieving revision 1.119
> diff -u -d -r1.118 -r1.119
> --- data.c	9 May 2009 21:21:43 -0000	1.118
> +++ data.c	21 May 2009 02:37:28 -0000	1.119
> @@ -924,5 +924,7 @@
>  int mapscaleFactor = 40;        /* allows for scaling of galactic window, unused */
>  int fullBitmapRotation = 1;     /* draw old bitmap sets to all angles */
>  int hideConsole = 0;            /* show console window or not */
> +int autoPhaser = 1;             /* phaser exact location of enemy target closest to cursor */
> +int useAllFeatures = 1;         /* ignore server settings for info/control feature packets */
>  
>  struct context *context;
> 
> Index: feature.c
> ===================================================================
> RCS file: /cvsroot/netrek/client/netrekxp/src/feature.c,v
> retrieving revision 1.26
> retrieving revision 1.27
> diff -u -d -r1.26 -r1.27
> --- feature.c	9 May 2009 21:21:43 -0000	1.26
> +++ feature.c	21 May 2009 02:37:28 -0000	1.27
> @@ -302,16 +302,26 @@
>  	    break;
>  	}
>      }
> -    /* Ignore these feature packets for testing purposes */
> -#if DEBUG
> -    motion_mouse_steering = 1;
> -    F_show_army_count = 1;
> -    F_show_other_speed = 1;
> -    F_show_cloakers = 1;
> -    F_turn_keys = 1;
> -    F_show_visibility_range = 1;
> -#endif
>  #endif /* BEEPLITE */
> +    /* Ignore these feature packets? */
> +    if (useAllFeatures)
> +    {
> +        motion_mouse_steering = 1;
> +        F_show_army_count = 1;
> +        F_show_other_speed = 1;
> +        F_show_cloakers = 1;
> +        F_turn_keys = 1;
> +        F_show_visibility_range = 1;
> +#ifdef BEEPLITE
> +        F_beeplite_flags = LITE_PLAYERS_MAP |
> +            LITE_PLAYERS_LOCAL |
> +            LITE_SELF |
> +            LITE_PLANETS |
> +            LITE_SOUNDS |
> +            LITE_COLOR |
> +            LITE_TTS;
> +#endif
> +    }
>  }
>  
>  /******************************************************************************/
> 
> Index: option.c
> ===================================================================
> RCS file: /cvsroot/netrek/client/netrekxp/src/option.c,v
> retrieving revision 1.57
> retrieving revision 1.58
> diff -u -d -r1.57 -r1.58
> --- option.c	21 May 2009 00:15:03 -0000	1.57
> +++ option.c	21 May 2009 02:37:28 -0000	1.58
> @@ -298,6 +298,7 @@
>  struct option Weapons_Menu[] = {
>      {0, "Weapons Menu", &MenuPage, 0, 0, 0, NULL, &Menus_Range},
>      {1, "Page %d (click to change)", &MenuPage, 0, 0, 0, NULL, &Menus_Range},
> +    {1, "use auto aim phasers", &autoPhaser, 0, 0, 0, NULL, NULL},
>      {1, "use color weapon bitmaps", &colorWeapons, 0, 0, 0, NULL, NULL},
>      {1, "show weapons on galactic", &weaponsOnMap, 0, 0, 0, NULL, NULL},
>  #ifdef JUBILEE_PHASERS
> @@ -438,6 +439,7 @@
>      {1, "", &messageHUD, 0, 0, 0, messagehudmess, &messagehud_range},
>  #endif
>      {1, "use double buffering", &doubleBuffering, 0, 0, 0, NULL, NULL},
> +    {1, "turn on all feature packets", &useAllFeatures, 0, 0, 0, NULL, NULL},
>      {1, "done", &notdone, 0, 0, 0, NULL, NULL},
>      {-1, NULL, 0, 0, 0, 0, NULL, NULL}
>  };
> 
> 
> _______________________________________________
> netrek-cvs mailing list
> netrek-cvs at us.netrek.org
> http://mailman.us.netrek.org/mailman/listinfo/netrek-cvs
> 

----- End forwarded message -----

-- 
"I'm sorry but our engineers do not have phones."
As stated by a Network Solutions Customer Service representative when asked to
be put through to an engineer.

"My other computer is your windows box."
                                     Ralf Hildebrandt
<sxem> trying to play sturgeon while it's under attack is apparently not fun.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20090520/4eabede1/attachment-0001.pgp 

From mark at mark.mielke.cc  Wed May 20 22:33:11 2009
From: mark at mark.mielke.cc (Mark Mielke)
Date: Wed, 20 May 2009 23:33:11 -0400
Subject: [netrek-dev] [modemhero@users.sourceforge.net:
 [netrek-cvs]	client/netrekxp/src data.c, 1.118, 1.119 defaults.c, 1.96,
 1.97 feature.c, 1.26, 1.27 input.c, 1.47, 1.48 option.c, 1.57, 1.58]
In-Reply-To: <20090521025016.GT28528@frodo.gerdesas.com>
References: <20090521025016.GT28528@frodo.gerdesas.com>
Message-ID: <4A14CB77.5030802@mark.mielke.cc>

John R. Dennison wrote:
> Ok, seriously, this has gone far enough.  AutoPhaser?  Client ability to
> override server FeaturePackets?
>
> With the recent deprecation of RSA an admins ability of blocking clients
> is limited without server changes; changes which a rogue client
> developer can trivially bypass in any event.  
>
> This type of crap with Bill has been going on for far too many years
> now; this needs to be dealt with once and for all.  Feature packets
> exist so admins can limit client abilities on their servers and present
> an even playing field.  What makes Bill think he is above the law (per
> sae) and has the ability of doing whatever it is he wants?
>   

Curious: Is this the sort of "law" that can be enforced in a court 
system? :-)

Open source software using an open protocol on the Internet.

I think this is why the RSA key based system of "trust" was established 
in the first place. If the system of trust was disbarred - not really 
sure why anybody could be held guilty of anything other than moral 
misconduct, which at best means you can write "Bill is a bad boy" on 
www.netrek.org and draw further attention to him and his client. :-)

Can't have it both ways - either authorize clients, or don't. Right and 
wrong don't apply in either case except in the perspective of the person 
making the judgement. With authorized clients - I didn't "like" that I 
couldn't write my own client or modify somebody else's client and get it 
blessed without substantial effort on my part (beyond just proving that 
the features added are not considered game altering - which was all 
subjective anyways, which lead to introduction of feature packets in the 
first place). With no authorization required - I don't "like" that 
people can add software to their client that will make them have a leg 
up on me.

Somebody else might have a different value system. For example, doesn't 
it seem ridiculous that the captain of a space ship would have to plot 
torpedo intercept courses themselves in real time? Wouldn't we have 
weapons officers to provide this function? Wouldn't my space ship have 
an automatic defense protocol, such that if I am sleeping in my 
quarters, and a space ship appears on my bow, red alert would 
automatically raise the shields before I stumbled to the turbo shaft 
while putting on my shirt to make it to the bridge as quickly as 
possible, slapping my com badge shouting "bridge - what is happening to 
my ship?"

People take things too seriously. :-)

Hopefully this brought some amusement to somebody.

Cheers,
mark

-- 
Mark Mielke <mark at mielke.cc>



From netrek at gmail.com  Thu May 21 00:07:32 2009
From: netrek at gmail.com (Zachary Uram)
Date: Thu, 21 May 2009 01:07:32 -0400
Subject: [netrek-dev] [modemhero@users.sourceforge.net: [netrek-cvs]
	client/netrekxp/src data.c, 1.118, 1.119 defaults.c, 1.96,
	1.97 feature.c, 1.26, 1.27 input.c, 1.47, 1.48 option.c, 1.57, 1.58]
In-Reply-To: <4A14CB77.5030802@mark.mielke.cc>
References: <20090521025016.GT28528@frodo.gerdesas.com>
	<4A14CB77.5030802@mark.mielke.cc>
Message-ID: <ecfa260c0905202207s75fba8a6l5042e5767bb782b1@mail.gmail.com>

Hi Mark,

ST:TOS is still my favorite :-) And ST:NG is second. I wonder what the
torp wobble is on bronco servers now compared to those of the past?

Zach


From quozl at us.netrek.org  Thu May 21 00:07:44 2009
From: quozl at us.netrek.org (James Cameron)
Date: Thu, 21 May 2009 15:07:44 +1000
Subject: [netrek-dev] [modemhero@users.sourceforge.net:
	[netrek-cvs]	client/netrekxp/src data.c, 1.118,
	1.119 defaults.c, 1.96, 1.97	feature.c, 1.26, 1.27 input.c,
	1.47, 1.48 option.c, 1.57, 1.58]
In-Reply-To: <20090521025016.GT28528@frodo.gerdesas.com>
References: <20090521025016.GT28528@frodo.gerdesas.com>
Message-ID: <20090521050744.GI14013@us.netrek.org>

On Wed, May 20, 2009 at 09:50:17PM -0500, John R. Dennison wrote:
> Ok, seriously, this has gone far enough.  AutoPhaser?  Client ability to
> override server FeaturePackets?

This will tip game balance and change behaviour as users upgrade.  As
the tip continues, other active client developers will implement the
same feature.

Are there any changes to the data provided to the client by a server
that would serve to restore the balance?

> Feature packets exist so admins can limit client abilities on their
> servers and present an even playing field.

Yes, that was the design intention, but with the subversion of our RSA
implementation several years ago and the removal recently, the feature
packet design is left like Bugs Bunny running off a cliff ... it takes
but a few seconds, realisation hits, and gravity takes effect.

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


From ahn at orion.netrek.org  Thu May 21 09:28:33 2009
From: ahn at orion.netrek.org (Dave Ahn)
Date: Thu, 21 May 2009 10:28:33 -0400
Subject: [netrek-dev] [modemhero@users.sourceforge.net:
	[netrek-cvs]	client/netrekxp/src data.c, 1.118,
	1.119 defaults.c, 1.96, 1.97	feature.c, 1.26, 1.27 input.c,
	1.47, 1.48 option.c, 1.57, 1.58]
In-Reply-To: <20090521025016.GT28528@frodo.gerdesas.com>
References: <20090521025016.GT28528@frodo.gerdesas.com>
Message-ID: <20090521142833.GA5449@orion.netrek.org>

On Wed, May 20, 2009 at 09:50:17PM -0500, John R. Dennison wrote:
> Ok, seriously, this has gone far enough.  AutoPhaser?  Client ability to
> override server FeaturePackets?

I admit, that is a bit too much.

> With the recent deprecation of RSA an admins ability of blocking clients
> is limited without server changes; changes which a rogue client
> developer can trivially bypass in any event.  

The argument for the necessity of RSA for server admins to block clients does
not stand because the server admins stopped blocking clients in the first place
many years ago.  The argument that MacTrek was the reason for disabling RSA is
weak; when MacTrek added RSA support, the server admins should have re-enabled
RSA, but that didn't happen.  The entire RSA key infrastructure was pointless
to maintain because it was not used, though perhaps it did offer the "threat"
of revocation for a "rogue client."

> This type of crap with Bill has been going on for far too many years
> now; this needs to be dealt with once and for all.  Feature packets
> exist so admins can limit client abilities on their servers and present
> an even playing field.  What makes Bill think he is above the law (per
> sae) and has the ability of doing whatever it is he wants?

Actually, my recollection is that the intent of FP was to offer backwards
compatibility for older clients.  Eventually this morphed into disabling
certain borgish or semi-borgish features in blessed clients during INL games.

Your position seems to be that Netrek needs to be sustained and maintained
according to standards of the past.  There is merit to this argument, as many
of the code changes (in my useless opinion) in the last decade to both the
clients and the server would have created an uproar to old clue who were on the
INLC, WNLC or otherwise respected in the community.  Should we then revert all
these changes, too?  Towards what end?



From netrek at gmail.com  Thu May 21 21:31:30 2009
From: netrek at gmail.com (Zachary Uram)
Date: Thu, 21 May 2009 22:31:30 -0400
Subject: [netrek-dev] setgame terminate
Message-ID: <ecfa260c0905211931w751c15cg24d0f4067677d9a5@mail.gmail.com>

I was told by Quozl that the canonical way to stop the Vanilla server
was to run:
"setgame terminate"
And I recall this working a year ago, but now it doesn't:

zu22 at debian:~/vanilla/lib/tools$ ps axu |grep netrekd
zu22      4249  0.0  0.1   2156   512 pts/0    S    03:07   0:00 ./netrekd
zu22     13205  0.0  0.2   3912   740 pts/0    S+   05:24   0:00 grep netrekd
zu22 at debian:~/vanilla/lib/tools$ ./setgame terminate
Warning: Daemon not running!

So if the canonical method for stopping the server changed could
someone tell me what is the new method?

Zach


From collinp111 at gmail.com  Thu May 21 21:37:49 2009
From: collinp111 at gmail.com (Collin Pruitt)
Date: Thu, 21 May 2009 22:37:49 -0400
Subject: [netrek-dev] setgame terminate
In-Reply-To: <ecfa260c0905211931w751c15cg24d0f4067677d9a5@mail.gmail.com>
References: <ecfa260c0905211931w751c15cg24d0f4067677d9a5@mail.gmail.com>
Message-ID: <4A160FFD.2030100@gmail.com>

Zachary Uram wrote:
> I was told by Quozl that the canonical way to stop the Vanilla server
> was to run:
> "setgame terminate"
> And I recall this working a year ago, but now it doesn't:
>
> zu22 at debian:~/vanilla/lib/tools$ ps axu |grep netrekd
> zu22      4249  0.0  0.1   2156   512 pts/0    S    03:07   0:00 ./netrekd
> zu22     13205  0.0  0.2   3912   740 pts/0    S+   05:24   0:00 grep netrekd
> zu22 at debian:~/vanilla/lib/tools$ ./setgame terminate
> Warning: Daemon not running!
>
> So if the canonical method for stopping the server changed could
> someone tell me what is the new method?
>
> Zach
>
> _______________________________________________
> netrek-dev mailing list
> netrek-dev at us.netrek.org
> http://mailman.us.netrek.org/mailman/listinfo/netrek-dev
>   
"killall netrekd" works fine for me.

(also, Canonical is a sponsor of Ubuntu, it is Ubuntu)

-- 
~Collin Pruitt - Hellow~
"Power corrupts and absolute power corrupts absolutely" - Lord Acton
http://wiki.ubuntu.com/Collin15 | http://launchpad.net/~hellow
Ubuntu Georgia LoCo Member | UF Beginners Team Member | Ubuntu Member

-------------- next part --------------
A non-text attachment was scrubbed...
Name: collinp111.vcf
Type: text/x-vcard
Size: 190 bytes
Desc: not available
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20090521/aa34291b/attachment.vcf 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20090521/aa34291b/attachment.pgp 

From quozl at us.netrek.org  Thu May 21 22:25:18 2009
From: quozl at us.netrek.org (James Cameron)
Date: Fri, 22 May 2009 13:25:18 +1000
Subject: [netrek-dev] setgame terminate
In-Reply-To: <4A160FFD.2030100@gmail.com>
References: <ecfa260c0905211931w751c15cg24d0f4067677d9a5@mail.gmail.com>
	<4A160FFD.2030100@gmail.com>
Message-ID: <20090522032518.GC15391@us.netrek.org>

Zachary Uram wrote:
> I was told by Quozl that the canonical way to stop the Vanilla server
> was to run:
> "setgame terminate"
> And I recall this working a year ago, but now it doesn't:
>
> zu22 at debian:~/vanilla/lib/tools$ ps axu |grep netrekd
> zu22      4249  0.0  0.1   2156   512 pts/0    S    03:07   0:00 ./netrekd
> zu22     13205  0.0  0.2   3912   740 pts/0    S+   05:24   0:00 grep netrekd
> zu22 at debian:~/vanilla/lib/tools$ ./setgame terminate
> Warning: Daemon not running!

It has successfully stopped the server daemon.  That is all it is for.
netrekd is not the daemon.

> So if the canonical method for stopping the server changed could
> someone tell me what is the new method?

It depends on what you mean by server.  There are at least three servers
involved in a Netrek Server.  There is the connection listener netrekd,
there is the universe simulator daemon, and there is the per-connection
task ntserv.

Before a game, only netrekd is active.

During a game, all three are active.

If you mean netrekd, the canonical method has not changed, and there are
no plans to change it:

	% netrekd stop

However, stopping netrekd does not stop a game in progress, nor should
it.  All it does is close the door to new connections.

I suggest you fix README.developers and submit a patch, thanks.  Use
darcs and emacs.  Or darcs and vi.  Or darcs and ed.  But do it.

Collin Pruitt wrote:
> "killall netrekd" works fine for me.

This is effectively what "netrekd stop" does.

> (also, Canonical is a sponsor of Ubuntu, it is Ubuntu)

"canonical" is a word that predates the corporation of which you speak.
http://en.wiktionary.org/wiki/canonical

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


From basic at us.netrek.org  Thu May 28 01:55:09 2009
From: basic at us.netrek.org (Bob Tanner)
Date: Thu, 28 May 2009 01:55:09 -0500
Subject: [netrek-dev] objective-c, cocoa, and the learning curve
Message-ID: <gvlcgd$8vd$1@ger.gmane.org>

As previously discussed here:

Archived-At:	<http://permalink.gmane.org/gmane.games.netrek.devel/2614>
Archived-At:	<http://permalink.gmane.org/gmane.games.netrek.devel/2608>

And

Archived-At:	<http://permalink.gmane.org/gmane.games.netrek.devel/2577>

I offered to pickup and help with the development of the netrek client for osx.

At the time I had never written a line of objective-c. Cocoa was 
something chocolate, served hot, with marshmellows. So, I started down 
the path of "Hello, world!".

As I dabbled I made little projects, licensed them under GPLv2, and put 
them into bzr.

I will start to put these little projects into launchpad so others who 
wish to start down the netrek-for-osx development path will have 
example code to look at.

In each project, I tried to incorporate a feature or features I felt 
would be useful in mactrek.

The first project I've put up in launchpad is called FirstApp (nice 
huh?) and it uses the Sparkle
(http://sparkle.andymatuschak.org) framework for self-updating.

You can view code here: https://code.launchpad.net/~tanner/+junk/xcode+FirstApp
You can get the code here: bzr branch lp:~tanner/+junk/xcode+FirstApp

By default, the xcode project compiles a 0.1 release of FirstApp, I 
have 0.2 release online (via appcast). So after running FirstApp 2 time 
(see http://tinyurl.com/4bbwhe #5 for details) you should get the 
auto-update window.

FirstApp demonstrates the use of Sparkle for self-updating osx 
applications. Which I think would be a useful feature in mactrek.

NOTE: Release 0.2 is 10.5/i386 application so if you aren't 10.5 and 
aren't i386 things will be ugly! I have since learned how to compile 
universal binaries (i386/ppc) but Sparkle requires you to split 
revisions of osx and I do not have anything but 10.5 systems.
-- 
Bob Tanner <basic at us.netrek.org>          
Key fingerprint = F785 DDFC CF94 7CE8 AA87 3A9D 3895 26F1 0DDB E378




From quozl at us.netrek.org  Thu May 28 02:45:05 2009
From: quozl at us.netrek.org (James Cameron)
Date: Thu, 28 May 2009 17:45:05 +1000
Subject: [netrek-dev] objective-c, cocoa, and the learning curve
In-Reply-To: <gvlcgd$8vd$1@ger.gmane.org>
References: <gvlcgd$8vd$1@ger.gmane.org>
Message-ID: <20090528074505.GH6327@us.netrek.org>

Neat.

For your interest, my wife was sitting there writing something on our
MacBook, and the fan was spinning like crazy.  SSH'd in, and found
MacTrek had left behind a newstartd and was repeatedly forking "players
u unknown", which was failing and causing a crash process.

I don't *know* that MacTrek will always do this.  I thought of checking
the server code base used, but there is no source for it in the MacTrek
repository.  Puzzling.

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


From basic at us.netrek.org  Thu May 28 04:10:43 2009
From: basic at us.netrek.org (Bob Tanner)
Date: Thu, 28 May 2009 04:10:43 -0500
Subject: [netrek-dev] MacTrek had left behind a newstartd
Message-ID: <gvlkej$vpv$1@ger.gmane.org>

Starting new thread.

> For your interest, my wife was sitting there writing something on our
> MacBook, and the fan was spinning like crazy.  SSH'd in, and found
> MacTrek had left behind a newstartd and was repeatedly forking "players
> u unknown", which was failing and causing a crash process.

Looks like the server gets started in ServerControllerNew.m, quick look 
makes it seem pretty light on coding, like stuff is missing.

> 
> I don't *know* that MacTrek will always do this.  I thought of checking
> the server code base used, but there is no source for it in the MacTrek
> repository.  Puzzling.

svn co https://mactrek.svn.sourceforge.net/svnroot/mactrek/trunk mactrek

That didn't pull the 1.4.0 code base for you?

But I also see Resources/PRECOMPILED/INTEL and what looks like all the 
server stuff there, pretty tired right now, but I'll look to see if the 
xcode project compiles that. Seem odd that precompiled binaries come 
down with a svn checkout.


-- 
Bob Tanner <basic at us.netrek.org>          
Key fingerprint = F785 DDFC CF94 7CE8 AA87 3A9D 3895 26F1 0DDB E378




From quozl at us.netrek.org  Thu May 28 06:45:44 2009
From: quozl at us.netrek.org (James Cameron)
Date: Thu, 28 May 2009 21:45:44 +1000
Subject: [netrek-dev] MacTrek had left behind a newstartd
In-Reply-To: <gvlkej$vpv$1@ger.gmane.org>
References: <gvlkej$vpv$1@ger.gmane.org>
Message-ID: <20090528114544.GB5460@us.netrek.org>

On Thu, May 28, 2009 at 04:10:43AM -0500, Bob Tanner wrote:
> Starting new thread.
> 
> > For your interest, my wife was sitting there writing something on our
> > MacBook, and the fan was spinning like crazy.  SSH'd in, and found
> > MacTrek had left behind a newstartd and was repeatedly forking "players
> > u unknown", which was failing and causing a crash process.
> 
> Looks like the server gets started in ServerControllerNew.m, quick look 
> makes it seem pretty light on coding, like stuff is missing.

Reviewed, looks okay to me.  Start, stop, nothing much more is
necessary.  The killall is reasonable too, but it would have been better
to use "setgame terminate" ... and newstartd should have stopped itself
unless there were multiple instances accidentally started before the
pidfile was written.  Hmm.

Summarising, a start should be "newstartd", and a stop should be
"setgame terminate ; newstartd stop".

> > I don't *know* that MacTrek will always do this.  I thought of checking
> > the server code base used, but there is no source for it in the MacTrek
> > repository.  Puzzling.
> 
> svn co https://mactrek.svn.sourceforge.net/svnroot/mactrek/trunk mactrek
> 
> That didn't pull the 1.4.0 code base for you?

It did, yes, but not the server source.

> But I also see Resources/PRECOMPILED/INTEL and what looks like all the 
> server stuff there, pretty tired right now, but I'll look to see if the 
> xcode project compiles that. Seem odd that precompiled binaries come 
> down with a svn checkout.

Exactly.  So how do we fix a server problem on the embedded server?
With players u crashing, for instance.

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


From basic at us.netrek.org  Thu May 28 14:40:51 2009
From: basic at us.netrek.org (Bob Tanner)
Date: Thu, 28 May 2009 14:40:51 -0500
Subject: [netrek-dev] MacTrek had left behind a newstartd
References: <gvlkej$vpv$1@ger.gmane.org> <20090528114544.GB5460@us.netrek.org>
Message-ID: <gvmpc3$q3s$1@ger.gmane.org>

On 2009-05-28 06:45:44 -0500, James Cameron 
<quozl at us.netrek.org> said:

>> But I also see Resources/PRECOMPILED/INTEL and what looks like all the
>> server stuff there, pretty tired right now, but I'll look to see if the
>> xcode project compiles that. Seem odd that precompiled binaries come
>> down with a svn checkout.
> 
> Exactly.  So how do we fix a server problem on the embedded server?
> With players u crashing, for instance.

Chris on this mailing list?

I do not want to re-do all the work of getting the server compiled 
under osx if he has it done already.

-- 
Bob Tanner <basic at us.netrek.org>          
Key fingerprint = F785 DDFC CF94 7CE8 AA87 3A9D 3895 26F1 0DDB E378




From chris.lukassen at gmail.com  Thu May 28 15:07:51 2009
From: chris.lukassen at gmail.com (Chris Lukassen)
Date: Thu, 28 May 2009 22:07:51 +0200
Subject: [netrek-dev] netrek-dev Digest, Vol 51, Issue 18
In-Reply-To: <mailman.1.1243530002.16029.netrek-dev@us.netrek.org>
References: <mailman.1.1243530002.16029.netrek-dev@us.netrek.org>
Message-ID: <B972AED1-1448-4F21-8AAD-A5A628D741B9@gmail.com>

>>
>
> It did, yes, but not the server source.
>>

The server is an ugly hack of 2.12 if recall correctly, which, on my  
platforms has stopped working. It's precompiled because i did not know  
how to tell the server configure to create a universal binairy, so i  
ran it on intel and ppc and included the binairy. I was about to  
release 1.5.0 when i noticed the local server was no longer working,  
even with Bob Tanners client, i tried to build the 2.15 version but  
also to no avail.

Has anyone build the server on OS X 10.5.7?

cheers

C 


From basic at us.netrek.org  Thu May 28 15:13:46 2009
From: basic at us.netrek.org (Bob Tanner)
Date: Thu, 28 May 2009 15:13:46 -0500
Subject: [netrek-dev] MacTrek had left behind a newstartd
References: <B972AED1-1448-4F21-8AAD-A5A628D741B9@gmail.com>
Message-ID: <gvmr9q$q1$1@ger.gmane.org>

On 2009-05-28 15:07:51 -0500, Chris Lukassen 
<chris.lukassen at gmail.com> said:

> Has anyone build the server on OS X 10.5.7?

I'll see what I can do.

-- 
Bob Tanner <basic at us.netrek.org>          
Key fingerprint = F785 DDFC CF94 7CE8 AA87 3A9D 3895 26F1 0DDB E378




From cflrich at cfl.rr.com  Thu May 28 18:37:01 2009
From: cflrich at cfl.rr.com (cflrich)
Date: Thu, 28 May 2009 19:37:01 -0400
Subject: [netrek-dev] Client Blessing
Message-ID: <4A1F201D.7040706@cfl.rr.com>

Hello,

Having recently returned to Netrek, I've been looking for a timed game.  
However, it appears that RSA has, for some reason, been deprecated.  
Furthermore, it is not enforced, even on the clue servers.  Is there 
currently no scheme for verifying that a client is not giving its user 
an unfair advantage over the other players?

We must have some scheme for verifying that clients are valid.  Heck, 
most modern games spend a lot of their time ensuring an even playing 
field; look at CoD4/5 and Punkbuster, look at most MMOs (Lotro, WoW, 
etc) and their constant vigilance over client hacks.  This is as old as 
time, or at least, as old as gaming on the internet.  Make sure the 
other guy isn't cheating. 

How can you have a competitive game if you don't ensure a level playing 
field?

Thanks,
Rich




From ahn at orion.netrek.org  Fri May 29 00:46:58 2009
From: ahn at orion.netrek.org (Dave Ahn)
Date: Fri, 29 May 2009 01:46:58 -0400
Subject: [netrek-dev] RES-RSA license change, standard Netrek license
Message-ID: <20090529054658.GA9208@orion.netrek.org>

In preparing an updated RES-RSA package, I have decided to place it explicitly
under the BSD license attached below.  If Ray Jones, Sam Shen, Nick Trown, Alec
Habig, Kurt Siegl, Bob Tanner and anyone else who have worked on it is on this
list, I would appreciate a quick email to this list or to me privately
indicating your explicit permission to do so.

Also, I'd like to make an effort to collect as many permissions as possible
from any and all past contributors to any and all forms of Netrek software.  If
you are such a person, please send me a private email with:

	1. Your name as you wish it to appear in the copyright statement.
	2. Any specfic software you worked on (COW, Vanilla, small patches here
	   and there, etc).
	3. Years you worked on that software (for the copyright statement).
	4. Your blanket permission to place all your past contributions to Netrek
	   under the BSD license below.

I have chosen the BSD license because it is most compatible with existing
copyright / permission statements in the current source code.  Any contributors
who might have wanted a more restrictive license (like GPL) would have placed
their code under such a license anyway.

Will this effort amount to anything, and could it stand up in a court of law?
Unknown.  But at a minimum I would like to compile a master COPYRIGHT file that
lists as many of the contributors as possible to give credit where credit is
due.

Dave / ahn at netrek.org

-----------------
Netrek License

Copyright (c) ....

All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:

    * Redistributions of source code must retain the above copyright notice,
      this list of conditions and the following disclaimer.

    * Redistributions in binary form must reproduce the above copyright
      notice, this list of conditions and the following disclaimer in the
      documentation and/or other materials provided with the distribution.

    * The names of the contributors may not be used to endorse or promote
      products derived from this software without specific prior written
      permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-----------------------


From basic at us.netrek.org  Fri May 29 04:06:51 2009
From: basic at us.netrek.org (Bob Tanner)
Date: Fri, 29 May 2009 04:06:51 -0500
Subject: [netrek-dev] osx branch of netrek-server live
Message-ID: <gvo8jb$953$1@ger.gmane.org>

Used fastexport <http://vmiklos.hu/project/darcs-fast-export/> and 
bzr's fastimport <http://bazaar-vcs.org/BzrFastImport> to "convert" 
Quozl's daracs repo into a bzr repo.

Since the RSA stuff has been removed I pushed  the branch to launchpad:

https://code.launchpad.net/~tanner/netrek-server/osx-branch

Terse announcement here:

https://launchpad.net/netrek-server/+announcement/2851

And the answer is yes, I'm building the osx branch using cmake. I'll 
post another day on why I switched.

-- 
Bob Tanner <basic at us.netrek.org>          
Key fingerprint = F785 DDFC CF94 7CE8 AA87 3A9D 3895 26F1 0DDB E378




From habig at neutrino.d.umn.edu  Fri May 29 08:53:02 2009
From: habig at neutrino.d.umn.edu (Alec T. Habig)
Date: Fri, 29 May 2009 08:53:02 -0500
Subject: [netrek-dev] RES-RSA license change, standard Netrek license
In-Reply-To: <20090529054658.GA9208@orion.netrek.org>
References: <20090529054658.GA9208@orion.netrek.org>
Message-ID: <20090529135302.GB5923@neutrino.d.umn.edu>

Dave Ahn writes:
> In preparing an updated RES-RSA package, I have decided to place it
> explicitly under the BSD license attached below.  If Ray Jones, Sam
> Shen, Nick Trown, Alec Habig, Kurt Siegl, Bob Tanner and anyone else
> who have worked on it is on this list, I would appreciate a quick
> email to this list or to me privately indicating your explicit
> permission to do so.

You've my permission.

       Alec

PS - anybody have an RPM of the client software?  Even though
blessedness seems passe these days, would rather have a packaged client
than a self-compiled one for ease of maintenance.

-- 
 	    Alec Habig, University of Minnesota Duluth Physics Dept.
	    		    habig at neutrino.d.umn.edu
		       http://neutrino.d.umn.edu/~habig/


From chris.lukassen at gmail.com  Fri May 29 16:16:46 2009
From: chris.lukassen at gmail.com (Chris Lukassen)
Date: Fri, 29 May 2009 23:16:46 +0200
Subject: [netrek-dev] OS X server
In-Reply-To: <mailman.1.1243616403.15885.netrek-dev@us.netrek.org>
References: <mailman.1.1243616403.15885.netrek-dev@us.netrek.org>
Message-ID: <46D1EE71-905A-4D57-87B5-0B41F0246F06@gmail.com>


On 29 May 2009, at 19:00, netrek-dev-request at us.netrek.org wrote:

>>
>> Has anyone build the server on OS X 10.5.7?
>
> I'll see what I can do.

That would be great, i had some trouble getting the initial version  
compiled, since i only want to link staticly (libgdbm.a) and use  
relative deployment paths (..) this allows the embedded server to be  
part of the app bundle and it can reside anywhere on the disk. (as  
aposed to fixed paths.)

I can build 2.15, run it, but clients get busted, not only mactrek,  
but also cow. So i must be doing something wrong on the server side.

cheers

C


From basic at us.netrek.org  Sat May 30 00:43:19 2009
From: basic at us.netrek.org (Bob Tanner)
Date: Sat, 30 May 2009 00:43:19 -0500
Subject: [netrek-dev] OS X server
References: <46D1EE71-905A-4D57-87B5-0B41F0246F06@gmail.com>
Message-ID: <gvqh1n$51d$1@ger.gmane.org>

On 2009-05-29 16:16:46 -0500, Chris Lukassen 
<chris.lukassen at gmail.com> said:

> I can build 2.15, run it, but clients get busted, not only mactrek,
> but also cow. So i must be doing something wrong on the server side.

I've muddled my way through a refactor of the code and got things to 
compile -as- darwin port thing. First attempt, trying to make it easy 
on myself.

James will hate my changes :-) So, I need to clean them up before 
submitting back to upstream.

Not sure if it's osx's version of gcc or default cflags, but lots of 
warnings. Looking at them as well.

-- 
Bob Tanner <basic at us.netrek.org>          
Key fingerprint = F785 DDFC CF94 7CE8 AA87 3A9D 3895 26F1 0DDB E378