From basic at us.netrek.org  Mon Mar  1 14:12:06 2010
From: basic at us.netrek.org (Bob Tanner)
Date: Mon, 1 Mar 2010 14:12:06 -0600
Subject: [netrek-dev] Tangently related to MacTrek and distribution
Message-ID: <hmh72m$d61$1@dough.gmane.org>

Just passing along this info.

Apple's native package tool "Package Maker" sucks to use when dealing 
with any sort of VCS. I've switched to this: 
http://s.sudre.free.fr/Software/Packages.html

Make sore a much better experience.

Just passing it along.

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




From netrek at gmail.com  Fri Mar  5 12:33:53 2010
From: netrek at gmail.com (Zachary Uram)
Date: Fri, 5 Mar 2010 13:33:53 -0500
Subject: [netrek-dev] minor bug?
Message-ID: <ecfa260c1003051033x7b9b9f24na387046c6d990d0f@mail.gmail.com>

I was quitting and during countdown someone geno'd in PreT and it
froze my countdown during the geno parade and then cancelled it so I
had to press shift-q again.

Zach

<>< http://www.fidei.org ><>


From jrd at gerdesas.com  Fri Mar  5 13:36:25 2010
From: jrd at gerdesas.com (John R. Dennison)
Date: Fri, 5 Mar 2010 13:36:25 -0600
Subject: [netrek-dev] minor bug?
In-Reply-To: <ecfa260c1003051033x7b9b9f24na387046c6d990d0f@mail.gmail.com>
References: <ecfa260c1003051033x7b9b9f24na387046c6d990d0f@mail.gmail.com>
Message-ID: <20100305193624.GA19967@frodo.gerdesas.com>

On Fri, Mar 05, 2010 at 01:33:53PM -0500, Zachary Uram wrote:
> I was quitting and during countdown someone geno'd in PreT and it
> froze my countdown during the geno parade and then cancelled it so I
> had to press shift-q again.

	Likely the same happens during the geno dance during a real
	t-mode victory.



							John
-- 
Mankind is a single body and each nation a part of that body.  We must
never say "What does it matter to me if some part of the world is ailing?"
If there is such an illness, we must concern ourselves with it as though we
were having that illness.

Mustafa Kemal Ataturk (1881-1938), founder and first President of the
Republic of Turkey
-------------- 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/20100305/7db6092e/attachment.pgp 

From quozl at us.netrek.org  Sun Mar  7 04:24:51 2010
From: quozl at us.netrek.org (James Cameron)
Date: Sun, 7 Mar 2010 21:24:51 +1100
Subject: [netrek-dev] minor bug?
In-Reply-To: <ecfa260c1003051033x7b9b9f24na387046c6d990d0f@mail.gmail.com>
References: <ecfa260c1003051033x7b9b9f24na387046c6d990d0f@mail.gmail.com>
Message-ID: <20100307102451.GA17013@us.netrek.org>

On Fri, Mar 05, 2010 at 01:33:53PM -0500, Zachary Uram wrote:
> I was quitting and during countdown someone geno'd in PreT and it
> froze my countdown during the geno parade and then cancelled it so I
> had to press shift-q again.

There are two critical data values;

- p_flags & PFSELFDEST, a bit in the player flags variable, which means
  that a self destruct timer is running,

- p_selfdest, a player variable, an integer representing the future game
  time (in terms of p_updates) that the self destruct will take effect
  if not cancelled.

PFSELFDEST is set in socket.c at the same point that you get the warning
"Self destruct initiated".  If you get that warning, PFSELFDEST is
certainly set.  Check your logs.  p_selfdest is set at the same moment,
to a time in the future (p_updates plus something).  See function
handleQuitReq.

PFSELFDEST is explicitly cleared under two conditions only:

1.  the self destruct timer expires, in which case your ship begins to
explode, and if the parade triggers at that point your explosion will
join the parade (your client may render this as a ship), and then the
end of parade explosion will change the reason for your death from what
you selected (you quit) to whatever triggered the parade (genocide),

2.  if a packet is received from the client forcing the cancel, in which
case you are told "Self Destruct has been canceled".  If you saw that
message, then your client sent a packet after the quit request.  Check
your logs.

PFSELFDEST is not cleared by the conquer parade, and the parade halts
the p_updates increment (it is a pause), so once the pause is finished
the fact that the ship is dead for reasons of genocide would hide the
PFSELFDEST flag.

PFSELFDEST is also cleared at the point a ship enters the game.  See
enter.c, function enter(), where p_flags is assigned rather than bit
manipulated.  Therefore the pending self destruct won't be seen by the
next ship in that slot.

In theory, the same problem you observe (self destruct ineffective)
might also occur if you are killed by an enemy before the timer
expires.  However, the typical client remembers you asked to quit.  COW
doesn't use PFSELFDEST at all.

The problem is no doubt caused by the original design overloading the
cause of death ... and offering only *one* cause of death in any
circumstance, instead of whatever causes are available.  Cause of death
should be a bit mask of possibilities, rather than a constant single
value.  Unlikely to change.

-- 
James Cameron
http://quozl.linux.org.au/


From cflrich at cfl.rr.com  Fri Mar 12 10:13:26 2010
From: cflrich at cfl.rr.com (cflrich)
Date: Fri, 12 Mar 2010 11:13:26 -0500
Subject: [netrek-dev] Voice
Message-ID: <4B9A6826.1020200@cfl.rr.com>

Hi all,

I'd like to implement voice communication in Netrek.  Unfortunately, I 
know very little about how voice works, so I went on a little hunting 
expedition this morning, and tried to wrap my head around it.  I guess 
the options are writing something from scratch, using the standard VoIP 
protocols, or integrate an existing product.  I saw mentioned in an old, 
old post, some software called Mumble, which is open source, so I had a 
look at that.  Mumble is the client, apparently, and the corresponding 
server is called Murmur.  Presumably the netrek server would run an 
instance or two of Murmur, and clients would run an instance of Mumble 
that connects.

Now, the fun will be coding it so that you auto-join your team's voice 
channel when you select your team.  How will this work?  Will the netrek 
server notify the client which team it is on, and therefore, which 
Murmur instance to sign on to, and Mumble will do that?  How can Mumble 
be commanded in such a fashion?  How will we prevent the others from 
connecting to the team channel?  How can we mute problem players?  
Should observers be allowed to speak?

I think its obvious from the above that I'm still wrapping my head 
around this stuff, but this is a project I'd like to work on, so, if 
anyone has any thoughts or suggestions on the above, let me know.  
Personally, I think this is the #1 thing missing from Netrek right now, 
and will vastly help things like teaching noobs, making the game more 
fun, and mainly just encourage teamwork due to the far faster and better 
communication that can be achieved with voice vs macros.

Thanks,
Rich



From list2rado at gmx.de  Fri Mar 12 10:39:50 2010
From: list2rado at gmx.de (Rado S)
Date: Fri, 12 Mar 2010 17:39:50 +0100
Subject: [netrek-dev] Voice
In-Reply-To: <4B9A6826.1020200@cfl.rr.com>
References: <4B9A6826.1020200@cfl.rr.com>
Message-ID: <20100312163950.GA13758@rzdspc10.informatik.uni-hamburg.de>

=- cflrich wrote on Fri 12.Mar'10 at 11:13:26 -0500 -=

> Personally, I think this is the #1 thing missing from Netrek right
> now, and will vastly help things like teaching noobs, making the
> game more fun, and mainly just encourage teamwork due to the far
> faster and better communication that can be achieved with voice vs
> macros.

... unless some unlucky noob meets the wrong guys, which can turn
them as fast away. But that's a general social problem, go ahead
with your project.
Anyway, how would voice-style interact with macros-style?
Would be a pity to miss the labs players which can't speak loudly.

-- 
? Rado S. -- You must provide YOUR effort for your goal!
EVERY effort counts: at least to show your attitude.
You're responsible for ALL you do: you get what you give.


From quozl at us.netrek.org  Fri Mar 12 15:33:28 2010
From: quozl at us.netrek.org (James Cameron)
Date: Sat, 13 Mar 2010 08:33:28 +1100
Subject: [netrek-dev] Voice
In-Reply-To: <4B9A6826.1020200@cfl.rr.com>
References: <4B9A6826.1020200@cfl.rr.com>
Message-ID: <20100312213327.GV3260@us.netrek.org>

On Fri, Mar 12, 2010 at 11:13:26AM -0500, cflrich wrote:
> Mumble is the client, apparently, and the corresponding server is
> called Murmur.  Presumably the netrek server would run an instance or
> two of Murmur, and clients would run an instance of Mumble that
> connects.

Yes.  We chose Mumble because of the licensing and the availability of
packages for netrek.org servers, which are Debian based.

> Now, the fun will be coding it so that you auto-join your team's voice 
> channel when you select your team.  How will this work?  Will the netrek 
> server notify the client which team it is on, and therefore, which 
> Murmur instance to sign on to, and Mumble will do that?  How can Mumble 
> be commanded in such a fashion?  How will we prevent the others from 
> connecting to the team channel?  How can we mute problem players?  
> Should observers be allowed to speak?

All good questions.  The answers differ according to whether we are
creating community policy, easing development, or other purposes.

Community policy ... voice contact should be optional, should only be
available to someone with a slot in the game, should default to be
private to the team, with the option of broadcast to all players, and
the option to block certain players from your ear.

I don't think there's any sense in trying to block the other team from
your team channel, as long as the only ones who may connect are those
who have slots in the team.  We already have the possibility of observer
cheating.

Anyway, it's nice to hear someone take this further.  I'm available to
assist, off-list or on-list.

-- 
James Cameron
http://quozl.linux.org.au/


From jrd at gerdesas.com  Fri Mar 12 15:47:25 2010
From: jrd at gerdesas.com (John R. Dennison)
Date: Fri, 12 Mar 2010 15:47:25 -0600
Subject: [netrek-dev] Voice
In-Reply-To: <20100312163950.GA13758@rzdspc10.informatik.uni-hamburg.de>
References: <4B9A6826.1020200@cfl.rr.com>
	<20100312163950.GA13758@rzdspc10.informatik.uni-hamburg.de>
Message-ID: <20100312214724.GG6989@frodo.gerdesas.com>

On Fri, Mar 12, 2010 at 05:39:50PM +0100, Rado S wrote:
> 
> ... unless some unlucky noob meets the wrong guys, which can turn
> them as fast away. But that's a general social problem, go ahead
> with your project.

	So nice we have your blessing on this.  I'm not sure what we
	would do without it.

> Anyway, how would voice-style interact with macros-style?

	Ideally the only voice that would not be opt-in would
	be RCDs converted to voice.  Everything else should
	require user intervention to specifically enable; at
	least on pickup.

	I can just see the parents lining up to complain about
	voice communications to their underage children.

	Rich,

	Have you investigated bandwidth utilization requirements
	for this?  Assuming full 16 slots of players and lets
	say 4 observer slots, with a lot of chatter.





							John

-- 
When good is dumb, evil will always triumph.

-- Jeff Atwood, 28 May 2008, Coding Horror Blog, 23 November 2000
-------------- 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/20100312/960b8f0e/attachment.pgp 

From netrek at gmail.com  Fri Mar 12 16:20:58 2010
From: netrek at gmail.com (Zachary Uram)
Date: Fri, 12 Mar 2010 17:20:58 -0500
Subject: [netrek-dev] Voice
In-Reply-To: <4B9A6826.1020200@cfl.rr.com>
References: <4B9A6826.1020200@cfl.rr.com>
Message-ID: <ecfa260c1003121420k23784378u3c7abce5f9a45ad5@mail.gmail.com>

Ideally it would meet COPPA compliance or else server admins may find
themselves under criminal and civil suits. As John mentioned parents
will freak out if they walk into their child's room and hear some
player shouting certain things. In Pennsylvania it is a crime to
knowingly say sexual content at a minor. The law has more leeway on
printed speech but laws governing voice abuses are much more long
established and clearly codified. Also how do you deal with general
abuse such as someone yelling a vulgar insult or even SHUT UP etc. It
is very different hearing someone's voice with emotional content
rather than just seeing the text. If implemented it should only
broadcast to player's who explicitly opt-in.

Zach

<>< http://www.fidei.org ><>


From cflrich at cfl.rr.com  Fri Mar 12 16:58:29 2010
From: cflrich at cfl.rr.com (cflrich)
Date: Fri, 12 Mar 2010 17:58:29 -0500
Subject: [netrek-dev] Voice
In-Reply-To: <20100312214724.GG6989@frodo.gerdesas.com>
References: <4B9A6826.1020200@cfl.rr.com>	<20100312163950.GA13758@rzdspc10.informatik.uni-hamburg.de>
	<20100312214724.GG6989@frodo.gerdesas.com>
Message-ID: <4B9AC715.1080509@cfl.rr.com>

Thanks for all of the replies, glad there is interest.  Here come some 
replies to some stuff:

John R. Dennison wrote:
> 	Rich,
>
> 	Have you investigated bandwidth utilization requirements
> 	for this?  Assuming full 16 slots of players and lets
> 	say 4 observer slots, with a lot of chatter.
>
>   
Here's what the Mumble FAQ has to say on that:


    What are the bandwidth requirements?

 From 0.9.1, this is highly variable, and mostly up to the user. With 
top quality, minimum latency and positional information sent, it is 
133.6 kbit/s including the IP and UDP overhead. With 60 ms transmission 
delay, the lowest quality speech and no positional information, it is 
17.4 kbit/s (again with IP and UDP overhead). The default quality 
setting uses 58.8 kbit/s. When comparing with other products, remember 
to compare the total bandwidth use and not just the bitrate of the audio 
encoding.

There are two parts to tuning the bandwidth; the audio bitrate per audio 
frame (e.g. 10ms) and the amount of frames to put in each packet. Each 
transmitted packet has a overhead of 28 bytes from IP and UDP alone, so 
at the highest transmission rate (100 packets per second), that is 2800 
bytes of data for raw network overhead alone. You should try to find a 
balance that works well for you, but we generally recommend sacrificing 
high audio bitrate for lower latency; Mumble sounds quite good even on 
the lowest quality setting.

There is no way to adjust the amount of incoming bandwidth; you will 
have to have enough to sustain the total amount of speaking players. 
This should be a minor issue; most players these days are on asymmetric 
lines and hence it is only upload that is a bottleneck.


    What sort of bandwidth will I need for the server?

Worst case scenario: Number of users ? Number of talking users ? 133,6 
kbit/s. With less aggressive quality settings, it's ~60 kbit/s, and the 
bare minimum is 17.4kbit/s. Note that Mumble is geared towards social 
gaming; its quality enables people to talk naturally to each other 
instead of just barking short commands, so the amount of "users talking 
at the same time" can be somewhat higher than expected.

This means that a server with 20 players and 2 players talking at once 
requires 1-3 Mbit/s, depending on quality settings. In the server's .ini 
file, you can specify the maximum allowed bitrate for users as well as 
the maximum number of clients to allow.

 From http://mumble.sourceforge.net/FAQ

Rich

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20100312/87e34e8a/attachment.htm 

From cflrich at cfl.rr.com  Fri Mar 12 17:09:06 2010
From: cflrich at cfl.rr.com (cflrich)
Date: Fri, 12 Mar 2010 18:09:06 -0500
Subject: [netrek-dev] Voice
In-Reply-To: <ecfa260c1003121420k23784378u3c7abce5f9a45ad5@mail.gmail.com>
References: <4B9A6826.1020200@cfl.rr.com>
	<ecfa260c1003121420k23784378u3c7abce5f9a45ad5@mail.gmail.com>
Message-ID: <4B9AC992.8070402@cfl.rr.com>

Well, in terms of any compliance, this should simply be a matter of an 
addition to the EULA of the client.  It is no longer the case that 
having voice communication in a game is an exotic feature; nearly every 
game either supports it directly, or the players require the other 
players to use ventrilo/teamspeak servers to remain competitive.  Many 
MMOs have voice communication built into groups these days.  These 
things are self policing, and this is fairly effective.  You deal with 
vulgur voice the same way you deal with vulgar chat: via the ignore 
function.  Additionally, many have a mute feature, allowing a team 
leader to mute offending players, although I don't think this particular 
mechanic will translate to pickup netrek.

In my experience (and I have quite a bit with using voice 
communication), people are far less likely to abuse it in the manner 
described  than they are text chat, mostly because its a little less 
anonymous, and people can directly and quickly tell them to stop.  In 
any event, avoiding putting something like this in because of these 
concerns is, I think, short-sighted.

As for which players opt-in, once voice communication is in the game, 
most players will require other players to use it, or at least have the 
ability to hear commands as they are relayed.  It is just so much faster 
and more effective.  You can have it be opt-in, but the player who is 
not using voice will be at a severe tactical disadvantage to the players 
who do, and so will his team.  This will take care of itself naturally 
as the players and teams using voice communication respond more 
quickly.  Noobs not reading will become less important, because every 
noob can hear.  This is a good thing.

Anyways, thanks again for all of the responses!

Zachary Uram wrote:
> Ideally it would meet COPPA compliance or else server admins may find
> themselves under criminal and civil suits. As John mentioned parents
> will freak out if they walk into their child's room and hear some
> player shouting certain things. In Pennsylvania it is a crime to
> knowingly say sexual content at a minor. The law has more leeway on
> printed speech but laws governing voice abuses are much more long
> established and clearly codified. Also how do you deal with general
> abuse such as someone yelling a vulgar insult or even SHUT UP etc. It
> is very different hearing someone's voice with emotional content
> rather than just seeing the text. If implemented it should only
> broadcast to player's who explicitly opt-in.
>
> Zach
>
> <>< http://www.fidei.org ><>
>
> _______________________________________________
> netrek-dev mailing list
> netrek-dev at us.netrek.org
> http://mailman.us.netrek.org/mailman/listinfo/netrek-dev
>
>   


-- 
Rich's Astro Blog-- http://cflastro.blogspot.com


From quozl at us.netrek.org  Fri Mar 12 17:35:27 2010
From: quozl at us.netrek.org (James Cameron)
Date: Sat, 13 Mar 2010 10:35:27 +1100
Subject: [netrek-dev] Voice
In-Reply-To: <4B9AC992.8070402@cfl.rr.com>
References: <4B9A6826.1020200@cfl.rr.com>
	<ecfa260c1003121420k23784378u3c7abce5f9a45ad5@mail.gmail.com>
	<4B9AC992.8070402@cfl.rr.com>
Message-ID: <20100312233527.GC13281@us.netrek.org>

On Fri, Mar 12, 2010 at 06:09:06PM -0500, cflrich wrote:
> In any event, avoiding putting something like this in because of these
> concerns is, I think, short-sighted.

+1

Even the text channel becomes useless for similar reasons, which is why
I don't use it.  RCDs only.

-- 
James Cameron
http://quozl.linux.org.au/


From jrd at gerdesas.com  Fri Mar 12 17:47:41 2010
From: jrd at gerdesas.com (John R. Dennison)
Date: Fri, 12 Mar 2010 17:47:41 -0600
Subject: [netrek-dev] Voice
In-Reply-To: <4B9AC992.8070402@cfl.rr.com>
References: <4B9A6826.1020200@cfl.rr.com>
	<ecfa260c1003121420k23784378u3c7abce5f9a45ad5@mail.gmail.com>
	<4B9AC992.8070402@cfl.rr.com>
Message-ID: <20100312234741.GH6989@frodo.gerdesas.com>

On Fri, Mar 12, 2010 at 06:09:06PM -0500, cflrich wrote:
> Well, in terms of any compliance, this should simply be a matter of an 
> addition to the EULA of the client.  It is no longer the case that 

	I don't understand.  I thought that the client was a standalone
	app that would run alongside the netrek client?  Is this not
	the case?  Does support have to be built into the netrek client
	itself?

	And no, I've not really spent any time reading up on this as I
	am slammed with work at the present time.

> having voice communication in a game is an exotic feature; nearly every 
> game either supports it directly, or the players require the other 
> players to use ventrilo/teamspeak servers to remain competitive.  Many 
> MMOs have voice communication built into groups these days.  These 
> things are self policing, and this is fairly effective.  You deal with 
> vulgur voice the same way you deal with vulgar chat: via the ignore 
> function.  Additionally, many have a mute feature, allowing a team 
> leader to mute offending players, although I don't think this particular 
> mechanic will translate to pickup netrek.

	Server admins should have the ability to squelch players as they
	see fit.  Their server, their bandwidth.

> In my experience (and I have quite a bit with using voice 
> communication), people are far less likely to abuse it in the manner 
> described  than they are text chat, mostly because its a little less 
> anonymous, and people can directly and quickly tell them to stop.  In 
> any event, avoiding putting something like this in because of these 
> concerns is, I think, short-sighted.

	User <-> User squelching should be handled by the server as
	ignores are currently handled, ":s" for example sent to the
	offending player.  I'd go so far as to say a new majority vote
	to silence a player might be useful, also.

> As for which players opt-in, once voice communication is in the game, 
> most players will require other players to use it, or at least have the 
> ability to hear commands as they are relayed.  It is just so much faster 
> and more effective.  You can have it be opt-in, but the player who is 
> not using voice will be at a severe tactical disadvantage to the players 
> who do, and so will his team.  This will take care of itself naturally 
> as the players and teams using voice communication respond more 
> quickly.  Noobs not reading will become less important, because every 
> noob can hear.  This is a good thing.

	While I agree that getting newbies more involved is good I
	really don't believe that voice is the end-all be-all that 
	many think it is.  It's easier to mentally tune out the fluff
	on Team and All boards than it will be to do the same to voice
	spam.  There is also the issue of understanding players and 
	language barriers that I feel might be an issue.  For what it's
	worth I won't use voice; I have no desire to hear twinks and I
	can RCD what needs to be done where faster than speak it; so 
	my investment in this is minimal other than just general
	opinion.

	And I feel bandwidth utilization may be an issue, but time
	will tell.

	Rich, are you going to want your darcs repo regenerated?






							John

-- 
"Whenever two people meet, there are really six people present. There is each
man as he sees himself, each man as the other person sees him, and each man
as he really is." 

--  William James
-------------- 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/20100312/6ec30595/attachment-0001.pgp 

From cflrich at cfl.rr.com  Fri Mar 12 18:39:04 2010
From: cflrich at cfl.rr.com (cflrich)
Date: Fri, 12 Mar 2010 19:39:04 -0500
Subject: [netrek-dev] Voice
In-Reply-To: <20100312234741.GH6989@frodo.gerdesas.com>
References: <4B9A6826.1020200@cfl.rr.com>
	<ecfa260c1003121420k23784378u3c7abce5f9a45ad5@mail.gmail.com>
	<4B9AC992.8070402@cfl.rr.com>
	<20100312234741.GH6989@frodo.gerdesas.com>
Message-ID: <4B9ADEA8.90300@cfl.rr.com>

Hey John,

John R. Dennison wrote:
> On Fri, Mar 12, 2010 at 06:09:06PM -0500, cflrich wrote:
>   
>> Well, in terms of any compliance, this should simply be a matter of an 
>> addition to the EULA of the client.  It is no longer the case that 
>>     
>
> 	I don't understand.  I thought that the client was a standalone
> 	app that would run alongside the netrek client?  Is this not
> 	the case?  Does support have to be built into the netrek client
> 	itself?	
>   
Ehhh, it is a standalone client, and it can run alongside the netrek.  
Support doesn't necessarily have to be built into the client, but we may 
want it to.  I'm not sure yet, still thinking it through.  I think it 
would be nicer if it were built in, but, that may be more work than its 
worth.  The important thing is that whatever is implemented is more 
robust than just someone buying a vent server and handing out the info 
to everyone.  This may be as simple as having the server detect which 
players are connected to which teams, and modifying the ACL to let them 
join the team voice.  I would like it that if the player selects 'voice 
enabled' in his client, this happens automatically for him, ie, he 
doesn't have to swap out, manually connect, etc etc.

Its something that still has to be looked at I guess.
> 	Server admins should have the ability to squelch players as they
> 	see fit.  Their server, their bandwidth.
>   
Absolutely, just like in text.

> 	User <-> User squelching should be handled by the server as
> 	ignores are currently handled, ":s" for example sent to the
> 	offending player.  I'd go so far as to say a new majority vote
> 	to silence a player might be useful, also.
>   
I agree here too.

> 	Rich, are you going to want your darcs repo regenerated?
>
>   
Yeah, probably, if you don't mind.  I'm not at the coding portion of 
this exercise yet, still trying to reason out exactly how this is going 
to function, which right now is reading up on mumble/murmur.

Thanks,
Rich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20100312/2e12c265/attachment.htm 

From netrek at gmail.com  Fri Mar 12 18:59:45 2010
From: netrek at gmail.com (Zachary Uram)
Date: Fri, 12 Mar 2010 19:59:45 -0500
Subject: [netrek-dev] Voice
In-Reply-To: <4B9AC992.8070402@cfl.rr.com>
References: <4B9A6826.1020200@cfl.rr.com>
	<ecfa260c1003121420k23784378u3c7abce5f9a45ad5@mail.gmail.com> 
	<4B9AC992.8070402@cfl.rr.com>
Message-ID: <ecfa260c1003121659u3c66dac9u7fba0191ff42b0db@mail.gmail.com>

On Fri, Mar 12, 2010 at 6:09 PM, cflrich <cflrich at cfl.rr.com> wrote:
>
> As for which players opt-in, once voice communication is in the game,
> most players will require other players to use it, or at least have the
> ability to hear commands as they are relayed. ?It is just so much faster
> and more effective. ?You can have it be opt-in, but the player who is
> not using voice will be at a severe tactical disadvantage to the players
> who do, and so will his team. ?This will take care of itself naturally
> as the players and teams using voice communication respond more
> quickly. ?Noobs not reading will become less important, because every
> noob can hear. ?This is a good thing.

It does have nice potential for helping newbies. Perhaps if a newbie
is flagged as such they can be added to a special voice channel in
which they will receive personalized instruction. They may find the
regular voice chat to be a bit too much. Also if someone is being
abusive, screaming at a newbie for example, there should be a
mechanism in place to mute them and if they do it repeatedly to lose
voice privileges for good.

Zach


From quozl at us.netrek.org  Fri Mar 12 20:15:27 2010
From: quozl at us.netrek.org (James Cameron)
Date: Sat, 13 Mar 2010 13:15:27 +1100
Subject: [netrek-dev] Voice
In-Reply-To: <ecfa260c1003121659u3c66dac9u7fba0191ff42b0db@mail.gmail.com>
References: <4B9A6826.1020200@cfl.rr.com>
	<ecfa260c1003121420k23784378u3c7abce5f9a45ad5@mail.gmail.com>
	<4B9AC992.8070402@cfl.rr.com>
	<ecfa260c1003121659u3c66dac9u7fba0191ff42b0db@mail.gmail.com>
Message-ID: <20100313021527.GA21469@us.netrek.org>

On Fri, Mar 12, 2010 at 07:59:45PM -0500, Zachary Uram wrote:
> Also if someone is being abusive,
> screaming at a newbie for example, [...]

That's something that voice contact does much better, and I'd prefer to
leave newbie contact fully enabled for that.  There's such an
educational benefit to being screamed at ... with reason ... in a small
group of people.

-- 
James Cameron
http://quozl.linux.org.au/


From cflrich at cfl.rr.com  Fri Mar 12 20:37:00 2010
From: cflrich at cfl.rr.com (cflrich)
Date: Fri, 12 Mar 2010 21:37:00 -0500
Subject: [netrek-dev] Voice
In-Reply-To: <20100313021527.GA21469@us.netrek.org>
References: <4B9A6826.1020200@cfl.rr.com>	<ecfa260c1003121420k23784378u3c7abce5f9a45ad5@mail.gmail.com>	<4B9AC992.8070402@cfl.rr.com>	<ecfa260c1003121659u3c66dac9u7fba0191ff42b0db@mail.gmail.com>
	<20100313021527.GA21469@us.netrek.org>
Message-ID: <4B9AFA4C.6060208@cfl.rr.com>

All,

After some reading, this is the architecture I'm leaning towards.  The 
server will run a Murmur instance, with separate channels for the 
teams.  When the player selects a team, the server will automatically 
reconfigure the access list to allow that player to enter the team 
channel, via Ice.  This is all server side.  On the client side, when 
the player selects a team, the (netrek) client would launch Mumble via 
command line, causing it to auto connect to Murmur in the proper channel.

Once connected, team changes can probably be handled by the server, 
moving the player automatically. 

A few questions to be answered are these.

- Will we require folks to pre-register with the Murmur server?  I'd 
rather not, honestly.
- How will we allow access?  I'm thinking when a player joins a game, 
the server will update Murmur's user list with the players name and a 
generated password, that is passed to the (netrek) client, which the 
client then uses to generate the Mumble session.

Obviously we'll need a little client support once this gets hashed out 
all the way, if we want to implement this so that it is automatic  Are 
all of the current client projects open projects?

Thanks,
Rich




From netrek at gmail.com  Fri Mar 12 20:38:47 2010
From: netrek at gmail.com (Zachary Uram)
Date: Fri, 12 Mar 2010 21:38:47 -0500
Subject: [netrek-dev] Voice
In-Reply-To: <20100313021527.GA21469@us.netrek.org>
References: <4B9A6826.1020200@cfl.rr.com>
	<ecfa260c1003121420k23784378u3c7abce5f9a45ad5@mail.gmail.com> 
	<4B9AC992.8070402@cfl.rr.com>
	<ecfa260c1003121659u3c66dac9u7fba0191ff42b0db@mail.gmail.com> 
	<20100313021527.GA21469@us.netrek.org>
Message-ID: <ecfa260c1003121838q51f7432bsf3aa8af73062f054@mail.gmail.com>

On Fri, Mar 12, 2010 at 9:15 PM, James Cameron <quozl at us.netrek.org> wrote:
>
> That's something that voice contact does much better, and I'd prefer to
> leave newbie contact fully enabled for that. ?There's such an
> educational benefit to being screamed at ... with reason ... in a small
> group of people.

I don't know many people that enjoy being screamed at. Being politely
told what they did wrong is one thing, but having players scream "YOU
F***ING MORON!" at a new player will likely just cause them to quit
and never play again. There are so many other games they can choose
where players are not allowed to do so they'll vote with their feet.

Zach


From netrek at gmail.com  Fri Mar 12 20:44:20 2010
From: netrek at gmail.com (Zachary Uram)
Date: Fri, 12 Mar 2010 21:44:20 -0500
Subject: [netrek-dev] Voice
In-Reply-To: <4B9AFA4C.6060208@cfl.rr.com>
References: <4B9A6826.1020200@cfl.rr.com>
	<ecfa260c1003121420k23784378u3c7abce5f9a45ad5@mail.gmail.com> 
	<4B9AC992.8070402@cfl.rr.com>
	<ecfa260c1003121659u3c66dac9u7fba0191ff42b0db@mail.gmail.com> 
	<20100313021527.GA21469@us.netrek.org> <4B9AFA4C.6060208@cfl.rr.com>
Message-ID: <ecfa260c1003121844w90a1515mb5c049e6a112ebe8@mail.gmail.com>

On Fri, Mar 12, 2010 at 9:37 PM, cflrich <cflrich at cfl.rr.com> wrote:
> All,
>
> After some reading, this is the architecture I'm leaning towards. ?The
> server will run a Murmur instance, with separate channels for the
> teams. ?When the player selects a team, the server will automatically
> reconfigure the access list to allow that player to enter the team
> channel, via Ice. ?This is all server side. ?On the client side, when
> the player selects a team, the (netrek) client would launch Mumble via
> command line, causing it to auto connect to Murmur in the proper channel.

Cool.

> Once connected, team changes can probably be handled by the server,
> moving the player automatically.
>
> A few questions to be answered are these.
>
> - Will we require folks to pre-register with the Murmur server? ?I'd
> rather not, honestly.
> - How will we allow access? ?I'm thinking when a player joins a game,
> the server will update Murmur's user list with the players name and a
> generated password, that is passed to the (netrek) client, which the
> client then uses to generate the Mumble session.

I'm not keen on registering but would if it was essential. So if a
session was setup for a netrek game how do we make sure outsiders
could not intrude and make mischief? When I used team speak on
Leftovers anyone could connect if they knew a few pieces of info.

> Obviously we'll need a little client support once this gets hashed out
> all the way, if we want to implement this so that it is automatic ?Are
> all of the current client projects open projects?

All are except Paradise 2000 which hasn't been under active
development in years.

Zach


From jrd at gerdesas.com  Fri Mar 12 21:49:39 2010
From: jrd at gerdesas.com (John R. Dennison)
Date: Fri, 12 Mar 2010 21:49:39 -0600
Subject: [netrek-dev] Voice
In-Reply-To: <4B9ADEA8.90300@cfl.rr.com>
References: <4B9A6826.1020200@cfl.rr.com>
	<ecfa260c1003121420k23784378u3c7abce5f9a45ad5@mail.gmail.com>
	<4B9AC992.8070402@cfl.rr.com>
	<20100312234741.GH6989@frodo.gerdesas.com>
	<4B9ADEA8.90300@cfl.rr.com>
Message-ID: <20100313034938.GI6989@frodo.gerdesas.com>

On Fri, Mar 12, 2010 at 07:39:04PM -0500, cflrich wrote:
> >  
> Ehhh, it is a standalone client, and it can run alongside the netrek.  
> Support doesn't necessarily have to be built into the client, but we may 
> want it to.  I'm not sure yet, still thinking it through.  I think it 
> would be nicer if it were built in, but, that may be more work than its 
> worth.  The important thing is that whatever is implemented is more 
> robust than just someone buying a vent server and handing out the info 
> to everyone.  This may be as simple as having the server detect which 
> players are connected to which teams, and modifying the ACL to let them 
> join the team voice.  I would like it that if the player selects 'voice 
> enabled' in his client, this happens automatically for him, ie, he 
> doesn't have to swap out, manually connect, etc etc.

	If we can distribute the mumble client we can package it up so
	that it auto-locates the existing netrek.exe and wraps it in a
	cmd wrapper so that when a user wishes to play netrek it will
	start both clients at the same time.  If the existing client
	can't be located the installer can prompt for it.

	Similar is possible for *nix and I'd imagine for OSX.

	I 'spose I will have to read up on the client and server to see
	if it's feasible, but if the mumble client can just connect to
	the murmur server and get tossed to the proper channel based on 
	the players team without having user intervention that would
	be nice.  I would think something like this should be possible.

> Yeah, probably, if you don't mind.  I'm not at the coding portion of 
> this exercise yet, still trying to reason out exactly how this is going 
> to function, which right now is reading up on mumble/murmur.

	Not a problem.  As discussed in the game I'll have it up for ya
	this weekend.  Will just need a DSA public key from you.




							John

-- 
I want a government small enough to fit inside the Constitution.

-- DownsizeDC.org co-founder Harry Browne (1933-2006)
-------------- 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/20100312/b481c43f/attachment.pgp 

From netrek at gmail.com  Sat Mar 13 04:08:40 2010
From: netrek at gmail.com (Zachary Uram)
Date: Sat, 13 Mar 2010 05:08:40 -0500
Subject: [netrek-dev] Voice
In-Reply-To: <20100313034938.GI6989@frodo.gerdesas.com>
References: <4B9A6826.1020200@cfl.rr.com>
	<ecfa260c1003121420k23784378u3c7abce5f9a45ad5@mail.gmail.com> 
	<4B9AC992.8070402@cfl.rr.com>
	<20100312234741.GH6989@frodo.gerdesas.com> 
	<4B9ADEA8.90300@cfl.rr.com> <20100313034938.GI6989@frodo.gerdesas.com>
Message-ID: <ecfa260c1003130208r38c31bf9le342f026c73afba9@mail.gmail.com>

In case anyone wants to include speech processing natively in a netrek
client there is an open-source speech codec with compression called
Speex. It is written in C:

http://www.speex.org/

There is also a Java port:
http://jspeex.sourceforge.net/

Zach


From quozl at us.netrek.org  Sun Mar 14 20:27:23 2010
From: quozl at us.netrek.org (James Cameron)
Date: Mon, 15 Mar 2010 12:27:23 +1100
Subject: [netrek-dev] Voice
In-Reply-To: <ecfa260c1003130208r38c31bf9le342f026c73afba9@mail.gmail.com>
References: <4B9A6826.1020200@cfl.rr.com>
	<ecfa260c1003121420k23784378u3c7abce5f9a45ad5@mail.gmail.com>
	<4B9AC992.8070402@cfl.rr.com>
	<20100312234741.GH6989@frodo.gerdesas.com>
	<4B9ADEA8.90300@cfl.rr.com>
	<20100313034938.GI6989@frodo.gerdesas.com>
	<ecfa260c1003130208r38c31bf9le342f026c73afba9@mail.gmail.com>
Message-ID: <20100315012723.GJ3798@us.netrek.org>

On Sat, Mar 13, 2010 at 05:08:40AM -0500, Zachary Uram wrote:
> In case anyone wants to include speech processing natively in a netrek
> client there is an open-source speech codec with compression called
> Speex.

Mumble uses Speex for several purposes, not just as a codec.  Mumble can
be linked natively in a Netrek client, but we might not need to do that;
it may be enough to run it parallel and pay the context switch costs.

-- 
James Cameron
http://quozl.linux.org.au/


From quozl at us.netrek.org  Sun Mar 14 20:25:35 2010
From: quozl at us.netrek.org (James Cameron)
Date: Mon, 15 Mar 2010 12:25:35 +1100
Subject: [netrek-dev] Voice
In-Reply-To: <4B9AFA4C.6060208@cfl.rr.com>
References: <4B9A6826.1020200@cfl.rr.com>
	<ecfa260c1003121420k23784378u3c7abce5f9a45ad5@mail.gmail.com>
	<4B9AC992.8070402@cfl.rr.com>
	<ecfa260c1003121659u3c66dac9u7fba0191ff42b0db@mail.gmail.com>
	<20100313021527.GA21469@us.netrek.org>
	<4B9AFA4C.6060208@cfl.rr.com>
Message-ID: <20100315012535.GI3798@us.netrek.org>

On Fri, Mar 12, 2010 at 09:37:00PM -0500, cflrich wrote:
> After some reading, this is the architecture I'm leaning towards.  The 
> server will run a Murmur instance, with separate channels for the 
> teams.  When the player selects a team, the server will automatically 
> reconfigure the access list to allow that player to enter the team 
> channel, via Ice.  This is all server side.  On the client side, when 
> the player selects a team, the (netrek) client would launch Mumble via 
> command line, causing it to auto connect to Murmur in the proper channel.

Sounds good.  Meets with my approval.

> Once connected, team changes can probably be handled by the server, 
> moving the player automatically. 

Heh, I'd forgotten about that.  ;-}

> A few questions to be answered are these.
> 
> - Will we require folks to pre-register with the Murmur server?  I'd 
> rather not, honestly.

Agreed, rather not.  We have a registration system already; the player
database, and hooks in the code ready for more formal registration
methods if required.

> - How will we allow access?  I'm thinking when a player joins a game, 
> the server will update Murmur's user list with the players name and a 
> generated password, that is passed to the (netrek) client, which the 
> client then uses to generate the Mumble session.

Agreed.  Call it a key or a passphrase if necessary.  But it has to be
within the existing server to client message stream.

Remember; can't use IP address for anything useful, in an access control
scenario; there are situations where more than one user is visible from
one IP, as far as the server is concerned.

> Obviously we'll need a little client support once this gets hashed out 
> all the way, if we want to implement this so that it is automatic  Are 
> all of the current client projects open projects?

Yes, all of the current client projects are open.  I'm in charge of
netrek-client-cow (which is packaged on Ubuntu and Debian), and the
netrek-client-pygame source.  Bill is in charge of the Windows client.

No other clients are actively developed ... active development would be
required for adding voice.

-- 
James Cameron
http://quozl.linux.org.au/


From netrek at gmail.com  Sun Mar 14 20:39:25 2010
From: netrek at gmail.com (Zachary Uram)
Date: Sun, 14 Mar 2010 21:39:25 -0400
Subject: [netrek-dev] Voice
In-Reply-To: <20100315012723.GJ3798@us.netrek.org>
References: <4B9A6826.1020200@cfl.rr.com>
	<ecfa260c1003121420k23784378u3c7abce5f9a45ad5@mail.gmail.com> 
	<4B9AC992.8070402@cfl.rr.com>
	<20100312234741.GH6989@frodo.gerdesas.com> 
	<4B9ADEA8.90300@cfl.rr.com> <20100313034938.GI6989@frodo.gerdesas.com> 
	<ecfa260c1003130208r38c31bf9le342f026c73afba9@mail.gmail.com> 
	<20100315012723.GJ3798@us.netrek.org>
Message-ID: <ecfa260c1003141839t440ca348o1f58e5df3c6151f8@mail.gmail.com>

On Sun, Mar 14, 2010 at 9:27 PM, James Cameron <quozl at us.netrek.org> wrote:
>
> Mumble uses Speex for several purposes, not just as a codec. ?Mumble can
> be linked natively in a Netrek client, but we might not need to do that;
> it may be enough to run it parallel and pay the context switch costs.

Ok.

Zach

<>< http://www.fidei.org ><>


From jrd at gerdesas.com  Sun Mar 14 20:46:52 2010
From: jrd at gerdesas.com (John R. Dennison)
Date: Sun, 14 Mar 2010 20:46:52 -0500
Subject: [netrek-dev] Voice
In-Reply-To: <20100315012723.GJ3798@us.netrek.org>
References: <4B9A6826.1020200@cfl.rr.com>
	<ecfa260c1003121420k23784378u3c7abce5f9a45ad5@mail.gmail.com>
	<4B9AC992.8070402@cfl.rr.com>
	<20100312234741.GH6989@frodo.gerdesas.com>
	<4B9ADEA8.90300@cfl.rr.com>
	<20100313034938.GI6989@frodo.gerdesas.com>
	<ecfa260c1003130208r38c31bf9le342f026c73afba9@mail.gmail.com>
	<20100315012723.GJ3798@us.netrek.org>
Message-ID: <20100315014651.GL6989@frodo.gerdesas.com>

On Mon, Mar 15, 2010 at 12:27:23PM +1100, James Cameron wrote:
> 
> Mumble uses Speex for several purposes, not just as a codec.  Mumble can
> be linked natively in a Netrek client, but we might not need to do that;
> it may be enough to run it parallel and pay the context switch costs.

	*Any* semi-modern machine is not going to have a problem 
	in doing so, and if someone *does* have an issue they need
	to upgrade their ancient junk in any event.




							John

-- 
<zu22> Hellow: bears are wonderful animals
<zu22> I love bears!
<zu22> I want to feed them marshmellows.
-------------- 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/20100314/95020a63/attachment.pgp 

From jrd at gerdesas.com  Sun Mar 14 20:52:22 2010
From: jrd at gerdesas.com (John R. Dennison)
Date: Sun, 14 Mar 2010 20:52:22 -0500
Subject: [netrek-dev] Voice
In-Reply-To: <20100315012535.GI3798@us.netrek.org>
References: <4B9A6826.1020200@cfl.rr.com>
	<ecfa260c1003121420k23784378u3c7abce5f9a45ad5@mail.gmail.com>
	<4B9AC992.8070402@cfl.rr.com>
	<ecfa260c1003121659u3c66dac9u7fba0191ff42b0db@mail.gmail.com>
	<20100313021527.GA21469@us.netrek.org>
	<4B9AFA4C.6060208@cfl.rr.com> <20100315012535.GI3798@us.netrek.org>
Message-ID: <20100315015222.GM6989@frodo.gerdesas.com>

On Mon, Mar 15, 2010 at 12:25:35PM +1100, James Cameron wrote:
> 
> Yes, all of the current client projects are open.  I'm in charge of
> netrek-client-cow (which is packaged on Ubuntu and Debian), and the
> netrek-client-pygame source.  Bill is in charge of the Windows client.
> 
> No other clients are actively developed ... active development would be
> required for adding voice.

	I'd argue that mactrek is still active; and if not that needs
	to change as their as a good number of mactrek users.

	Also, mactrek has speech recognition if I'm not mistaken; how
	would that interact with mumble?




							John
-- 
Normal is getting dressed in clothes that you buy for work and driving
through traffic in a car that you are still paying for -- in order to get
to the job you need to pay for the clothes and the car, and the house you
leave vacant all day so you can afford to live in it.

-- Ellen Goodman (1941-), American journalist and
   Pulitzer Prize-winning syndicated columnist



-------------- 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/20100314/c5d1e515/attachment.pgp 

From quozl at us.netrek.org  Sun Mar 14 21:09:24 2010
From: quozl at us.netrek.org (James Cameron)
Date: Mon, 15 Mar 2010 13:09:24 +1100
Subject: [netrek-dev] Voice
In-Reply-To: <20100315015222.GM6989@frodo.gerdesas.com>
References: <4B9A6826.1020200@cfl.rr.com>
	<ecfa260c1003121420k23784378u3c7abce5f9a45ad5@mail.gmail.com>
	<4B9AC992.8070402@cfl.rr.com>
	<ecfa260c1003121659u3c66dac9u7fba0191ff42b0db@mail.gmail.com>
	<20100313021527.GA21469@us.netrek.org>
	<4B9AFA4C.6060208@cfl.rr.com> <20100315012535.GI3798@us.netrek.org>
	<20100315015222.GM6989@frodo.gerdesas.com>
Message-ID: <20100315020924.GM3798@us.netrek.org>

On Sun, Mar 14, 2010 at 08:52:22PM -0500, John R. Dennison wrote:
> 	I'd argue that mactrek is still active; and if not that needs
> 	to change as their as a good number of mactrek users.

Good catch.

> 	Also, mactrek has speech recognition if I'm not mistaken; how
> 	would that interact with mumble?

Interestingly.

-- 
James Cameron
http://quozl.linux.org.au/


From netrek at gmail.com  Tue Mar 16 02:31:16 2010
From: netrek at gmail.com (Zachary Uram)
Date: Tue, 16 Mar 2010 03:31:16 -0400
Subject: [netrek-dev] make current C based clients into Flash with Alchemy?
Message-ID: <ecfa260c1003160031m2448bbe4ha79025ea3af9d9bf@mail.gmail.com>

http://labs.adobe.com/technologies/alchemy/

Zach

<>< http://www.fidei.org ><>


From jrd at gerdesas.com  Tue Mar 16 02:41:38 2010
From: jrd at gerdesas.com (John R. Dennison)
Date: Tue, 16 Mar 2010 02:41:38 -0500
Subject: [netrek-dev] make current C based clients into Flash with
	Alchemy?
In-Reply-To: <ecfa260c1003160031m2448bbe4ha79025ea3af9d9bf@mail.gmail.com>
References: <ecfa260c1003160031m2448bbe4ha79025ea3af9d9bf@mail.gmail.com>
Message-ID: <20100316074137.GO6989@frodo.gerdesas.com>

On Tue, Mar 16, 2010 at 03:31:16AM -0400, Zachary Uram wrote:
> http://labs.adobe.com/technologies/alchemy/

	Good lord.

	Why?



						John

-- 
When good is dumb, evil will always triumph.

-- Jeff Atwood, 28 May 2008, Coding Horror Blog, 23 November 2000
-------------- 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/20100316/90315449/attachment.pgp 

From netrek at gmail.com  Tue Mar 16 02:50:21 2010
From: netrek at gmail.com (Zachary Uram)
Date: Tue, 16 Mar 2010 03:50:21 -0400
Subject: [netrek-dev] make current C based clients into Flash with
	Alchemy?
In-Reply-To: <20100316074137.GO6989@frodo.gerdesas.com>
References: <ecfa260c1003160031m2448bbe4ha79025ea3af9d9bf@mail.gmail.com> 
	<20100316074137.GO6989@frodo.gerdesas.com>
Message-ID: <ecfa260c1003160050v21585bdbse9d30b01f15098af@mail.gmail.com>

On Tue, Mar 16, 2010 at 3:41 AM, John R. Dennison <jrd at gerdesas.com> wrote:
>
> ? ? ? ?Good lord.
>
> ? ? ? ?Why?

Maybe it would be effective way to target people wary of downloading
and installing a client.
Lots of kids use library computers and it doesn't let you download and
run .EXE but I think
they could run Flash.

Zach


From jrd at gerdesas.com  Tue Mar 16 03:12:01 2010
From: jrd at gerdesas.com (John R. Dennison)
Date: Tue, 16 Mar 2010 03:12:01 -0500
Subject: [netrek-dev] make current C based clients into Flash with
	Alchemy?
In-Reply-To: <ecfa260c1003160050v21585bdbse9d30b01f15098af@mail.gmail.com>
References: <ecfa260c1003160031m2448bbe4ha79025ea3af9d9bf@mail.gmail.com>
	<20100316074137.GO6989@frodo.gerdesas.com>
	<ecfa260c1003160050v21585bdbse9d30b01f15098af@mail.gmail.com>
Message-ID: <20100316081201.GP6989@frodo.gerdesas.com>

On Tue, Mar 16, 2010 at 03:50:21AM -0400, Zachary Uram wrote:
>
> Maybe it would be effective way to target people wary of downloading
> and installing a client.

	Oh, please.

> Lots of kids use library computers and it doesn't let you download and
> run .EXE but I think
> they could run Flash.

	And it would still likely be a violation of the policy of the
	institutions in question; I'm sure that libraries want their
	patrons using their resources to play netrek.

	Plus the last I checked flash was still a closed technology,
	didn't we go through the whole closed-source thing with Trent's
	client?  Do we want to go down that road again?

	Historically flash has also not been the most stable plugin;
	I still hear almost daily of incidents where flash barfs
	on both linux and win32/64 platforms.  Not to mention that
	I don't see flash being a viable platform for netrek
	requirements.

	IM(ns)HO, this is just a waste of time and effort; time and
	effort that could be much better spent elsewhere.




							John

-- 
All I ask is this: Do something.  Try something.  Speaking out, showing up,
writing a letter, a check, a strongly worded e-mail.  Pick a cause -- there
are few unworthy ones.  And nudge yourself past the brink of tacit support
to action.  Once a month, once a year, or just once.

-- Joss Whedon (1964-), writer and film director
-------------- 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/20100316/81fc6830/attachment.pgp 

From mark at mark.mielke.cc  Tue Mar 16 03:14:50 2010
From: mark at mark.mielke.cc (Mark Mielke)
Date: Tue, 16 Mar 2010 04:14:50 -0400
Subject: [netrek-dev] make current C based clients into Flash
	with	Alchemy?
In-Reply-To: <ecfa260c1003160050v21585bdbse9d30b01f15098af@mail.gmail.com>
References: <ecfa260c1003160031m2448bbe4ha79025ea3af9d9bf@mail.gmail.com>
	<20100316074137.GO6989@frodo.gerdesas.com>
	<ecfa260c1003160050v21585bdbse9d30b01f15098af@mail.gmail.com>
Message-ID: <4B9F3DFA.7030509@mark.mielke.cc>

On 03/16/2010 03:50 AM, Zachary Uram wrote:
> On Tue, Mar 16, 2010 at 3:41 AM, John R. Dennison<jrd at gerdesas.com>  wrote:
>    
>>         Good lord.
>>
>>         Why?
>>      
> Maybe it would be effective way to target people wary of downloading
> and installing a client.
> Lots of kids use library computers and it doesn't let you download and
> run .EXE but I think
> they could run Flash.
>    

In fact - a better question might be: If you were to re-write Netrek 
from scratch today - why WOULDN'T you use Flash?

I think people think of Flash as a complex animation suite. But, take a 
look at this:

http://www.adobe.com/products/flex/

Flex is somewhat like Adobe's re-write of Java mixed with rich user 
interface and rendering capabilities. That you can write a program in 
Flex and have it run in Flash, where Flash is generally available for 
most platforms and is often already installed on people's computers, 
makes it a great target.

Good lord. Why? Why *NOT*? :-)

Cheers,
mark



From mark at mark.mielke.cc  Tue Mar 16 03:32:49 2010
From: mark at mark.mielke.cc (Mark Mielke)
Date: Tue, 16 Mar 2010 04:32:49 -0400
Subject: [netrek-dev] make current C based clients into Flash
	with	Alchemy?
In-Reply-To: <20100316081201.GP6989@frodo.gerdesas.com>
References: <ecfa260c1003160031m2448bbe4ha79025ea3af9d9bf@mail.gmail.com>	<20100316074137.GO6989@frodo.gerdesas.com>	<ecfa260c1003160050v21585bdbse9d30b01f15098af@mail.gmail.com>
	<20100316081201.GP6989@frodo.gerdesas.com>
Message-ID: <4B9F4231.5060409@mark.mielke.cc>

On 03/16/2010 04:12 AM, John R. Dennison wrote:
> 	Plus the last I checked flash was still a closed technology,
> 	didn't we go through the whole closed-source thing with Trent's
> 	client?  Do we want to go down that road again?
>
> 	Historically flash has also not been the most stable plugin;
> 	I still hear almost daily of incidents where flash barfs
> 	on both linux and win32/64 platforms.  Not to mention that
> 	I don't see flash being a viable platform for netrek
> 	requirements.
>    

This is entirely FUD.

*Flex* is completely open as of release 3, and this is the programming 
language you would use to write your Flash applications in. Who cares 
whether the player is open source or not - as long as it is freely 
available?

Flash has been stable for 32-bit for many years, and stable for 64-bit 
for several years. Most Facebook applications that people waste their 
time on all day long are written in Flash. Why shouldn't people be 
wasting their time playing Netrek instead of Bejeweled Blitz?

Perhaps you are talking about the re-writes of Flash by the free / open 
source community that barely work?

> 	IM(ns)HO, this is just a waste of time and effort; time and
> 	effort that could be much better spent elsewhere.
>    

Another valuable reason to learn Flex, is that it can open job 
opportunities. Many companies are writing their client applications in 
Flex instead of Java these days as the Flex tools for mocking user 
interfaces is just cuter and more productive, and the Flex capabilities 
for making fancy graphics easily is just nice.

Cheers,
mark



From jrd at gerdesas.com  Tue Mar 16 04:31:06 2010
From: jrd at gerdesas.com (John R. Dennison)
Date: Tue, 16 Mar 2010 04:31:06 -0500
Subject: [netrek-dev] make current C based clients into Flash
	with	Alchemy?
In-Reply-To: <4B9F4231.5060409@mark.mielke.cc>
References: <ecfa260c1003160031m2448bbe4ha79025ea3af9d9bf@mail.gmail.com>
	<20100316074137.GO6989@frodo.gerdesas.com>
	<ecfa260c1003160050v21585bdbse9d30b01f15098af@mail.gmail.com>
	<20100316081201.GP6989@frodo.gerdesas.com>
	<4B9F4231.5060409@mark.mielke.cc>
Message-ID: <20100316093105.GQ6989@frodo.gerdesas.com>

On Tue, Mar 16, 2010 at 04:32:49AM -0400, Mark Mielke wrote:
> 
> This is entirely FUD.
> 
> *Flex* is completely open as of release 3, and this is the programming 
> language you would use to write your Flash applications in. Who cares 
> whether the player is open source or not - as long as it is freely 
> available?

	Well...  I care.  I'm locked into closed technologies quite
	often and frankly I don't care to be locked into even more.

	But that's me.  Others can, and will, think differently.

	As far as Flex being open or close I will be happy to take
	your word that it is open; I don't touch the thing and 
	wouldn't know the status if it jumped up and bit me.  But
	the player isn't :)

> Flash has been stable for 32-bit for many years, and stable for 64-bit 
> for several years. Most Facebook applications that people waste their 
> time on all day long are written in Flash. Why shouldn't people be 
> wasting their time playing Netrek instead of Bejeweled Blitz?

	FUD?

	I can trivially document memory leaks in FF using Flash.  I
	can trivially document CPU utilization issues with Flash.  All
	with the official adobe bits.  A rapid search shows that I am
	by no means the only such person on the net experiencing 
	similar behavior, Mark.

	Sorry, but I just can not consider this stable behavior.  

	Perhaps my work-flow differs from most other people and leads
	to this type of behavior?  That's possible.  I have 53 tabs 
	open in a single FF instance at the moment; and the browser
	process has been alive for a long time.  I also have no tabs
	with Flash content on them at the moment :)  If I did, I would
	have had to restart the browser by now.

	As far as wasting their time?  I don't care what people do with 
	their time; I don't see these people playing netrek, however.
	Perhaps I am just a realist and don't live in a world of pipe-dreams
	that some other list members do.

	By all means, put together a netrek client in Flash.  I'll bet
	you real green dollars right now that reiterates my original
	statement that it will just be a waste of time with little no
	no positive gain.  Actually, it would be a bet that I'd be
	happy to lose as my losing would be good for the game.

> Perhaps you are talking about the re-writes of Flash by the free / open 
> source community that barely work?

	No, of course not.

> Another valuable reason to learn Flex, is that it can open job 
> opportunities. Many companies are writing their client applications in 
> Flex instead of Java these days as the Flex tools for mocking user 
> interfaces is just cuter and more productive, and the Flex capabilities 
> for making fancy graphics easily is just nice.

	I can't argue this as I have no experience from a development
	standpoint.

	I'm really not trying to get into a long-winded discussion
	about this; it is quite apparent we disagree and I'm fine
	with that :)

	I did, however, take offense at the FUD label.  You may not
	agree with my statements but I'm not in the habit of posting
	FUD.  I stand by my statements that Flash is not stable; that
	Flash has memory leaks on multiple target platforms; and that
	Flash is a cpu hog especially over the course of time.

	In any event, I'm calling it a night.




							John

-- 
Never, never be afraid to do what's right, especially if the well-being of
a person or animal is at stake.  Society's punishments are small compared
to the wounds we inflict on our soul when we look the other way.

-- Martin Luther King Jr. (1929-1968), civil-rights leader
-------------- 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/20100316/1343f46e/attachment.pgp 

From netrek at gmail.com  Tue Mar 16 06:51:37 2010
From: netrek at gmail.com (Zachary Uram)
Date: Tue, 16 Mar 2010 07:51:37 -0400
Subject: [netrek-dev] cost of netrek
Message-ID: <ecfa260c1003160451m50c75773t523c890368873c75@mail.gmail.com>

According to this netrek is rich! It's worth $1,295,490 USD!

http://www.koders.com/info.aspx?c=ProjectInfo&pid=R5KDRSCZ4EF8NPGCK4LZFXCM5A

Zach

<>< http://www.fidei.org ><>


From bryansmart at bryansmart.com  Tue Mar 16 15:54:08 2010
From: bryansmart at bryansmart.com (Bryan Smart)
Date: Tue, 16 Mar 2010 16:54:08 -0400
Subject: [netrek-dev] Audio-based Netrek Client
Message-ID: <26DA767D4A3B96479F633389CA1DD33826360B994A@MAILSC004.mail.lan>

Hi Netrek dev community. I've joined the list to seek your advice. This is a fairly long post, but I hope that you will find the situation novel and the concept interesting.

I've been programming for about 20 years. I'm also blind. For those of you that aren't familiar with how that could be possible, many blind people use a class of software called a screen reader to translate a visual interface in to synthesized speech or Braille. Anyway, while I've programmed for a while professionally, one of my personal areas of interest are alternative user interfaces. The reasons for that interest are most likely quite obvious. A good way to experiment with these concepts has been to create computer games for blind users. Generically, these are now called audio games by our community. I know...screen readers, audio games...we need flashier terms. *smile*

The first audio games were specialized systems. A program was written specifically to convey all information directly through sound cues and synthesized speech. There are lots of simple games possible with that approach. Basically, the main difference between those games and a simple game with a visual interface is that the computer either reads all prompts, or describes the current situation.

After a few of those were made, the next stage was to determine how much of the presentation of the situation could be communicated with just audio. The most successful project from this stage was a project called Shades of Doom (Nothing to do with ID's Doom). This game used surround sound audio to allow someone to hear their environment while wearing headphones. Techniques used here included being able to hear footsteps echo from walls (so based on the echo delay, you can hear how close you are), hearing emphasized wind noises to indicate tunnels and passages (so people know when they have reached a fork in a hall, for example), and hearing cues to indicate equipment and power-ups that are on the ground. Speech still needs to be used to do things like describe an item once the player finds it, but the surround sound presentation greatly enhances the feel of being in a virtual space, and conveys detail that wouldn't be possible with just speech.

The most recent stage of this work has been to move beyond single-player and specialized games, and apply these concepts to mainstream games. One reason for that is to give blind players more people to play against than just other blind people. However, the cool technical aspect to it is that the audio client/blind client is just a different way of representing the game's interface. The best example of this so far has been a project to create an accessible version of the Quake client. This has worked out well. Sight is a higher bandwidth sense, but, we've been able to layer enough distinctive audio cues so that a blind player has enough information to navigate and avoid obstacles, hear the position and movement of other players and equipment, and target them. That has proven to be a really popular project.

A problem with that project, though, is that I think that we shot too high. There is so much audio information that you almost need to train people to be able to pick it all out at once and respond to it reflexively. Many players are dedicated, and have become very good at Audio Quake, but it is profoundly difficult for new users to jump in and start fragging.

So, this brings me to why I'm writing to you all. I think that an accessible (to the blind), client for Netrek would be a great experiment. I have some ideas regarding how I'll make everything work, but, being blind myself, I haven't played, nor can I use, the existing clients, so I'll be learning to play as I develop. That's how it went with Quake, though, so I don't imagine that it will be that bad.

Some aspects of the game, I can simply translate directly to audio. For example, instead of a top-down visual perspective on the map, I can use a first-person audio perspective. Instead of seeing a ship to your left, you'll hear the sound of a ship's engine to your left. If they fire a torpedo that streaks by you, you'll hear the torpedo streak by. I can make other positional sounds for planets, bases, etc. I don't imagine that this will cause any problems. I can, of course, add keyboard commands to speak the status of things like fuel level, position, etc.

However, there are some parts to the game that, no matter how hard I try, won't be completely balanced.

For example, one big problem that has come up when creating strategy games is that it is difficult for most blind users to get a quick overview of a complete map. This makes it difficult to provide them with ways to make decisions about where they should go, the status and arrangement of resources, etc. There are a few ways to partially overcome this problem, but they are far from perfect.

The first is that, instead of a map, I present them with a type of data view that shows all ships, planets, bases, etc, along with info about each. I provide keyboard commands to sort/refine this information. They can, for example, switch to showing only planets, only bases, only fed/rom/klingon objects, sort based on distance, number of armies, etc. This will permit strategy, but there is no way that they can take this info in as fast as looking at the galactic map.

Second, I can't think of a good way to make an accessible way of targeting an enemy with weapons, tractor beams, pressors, etc. I thought that I could turn on a targeting mode where they have a target ping that can be moved around their perspective. If the ping is moved ahead and to the left, for example, shooting a torpedo would fire it along that heading. It would be profoundly difficult to aim this way, though, so they'd be at a profound disadvantage.

Another approach would be to provide an automatic targeting feature, but there would need to be some sort of skill or limitation of that in order to keep it fair. I thought that either a constant probability could be set, or else the targeting accuracy would depend on a condition like the damage level of the computer or something. For the fixed probability, the software could compute a perfect heading, and then randomize it by something like 20%. It occurs to me, though, that even perfect targeting for something like a torpedo at launch time is no guaranty that the target won't dodge or something.

I know, from reading up on Netrek, though, that this would bring the accessible client in to cyborg territory. If someone came on a game with the accessible client, I wouldn't want the cyborg advantage such that people would feel like it was cheating.

Of course, it might be that I won't be able to figure out ways to help a blind player respond fast enough to the limitations in order to sufficiently compete against sighted players. If that happens, I would need to make a modified server that would only accept connections from the accessible client.
I'd prefer not to go this way, but, if I did, the first thing that I'd want to change is the speed of the game. Is there a central place in the server code that controls the rate of frame advance in the game? It is also possible that the server doesn't manage time that way (haven't looked at the server code yet). I'd like to do something like increase the time between frames by some factor like 4X, for example. Didn't see a config option for game speed, so I'm guessing that I'd need to recompile my own version of the server to make that happen.

OK. I think that this gives a good overview of the basics of what I'd like to do. Before I start going too deep with other ideas, I'd appreciate hearing feedback to know of any problems or other considerations that you all can think of, given your detailed experience with the system and code.

Thanks.

Bryan


From bryansmart at bryansmart.com  Tue Mar 16 14:44:03 2010
From: bryansmart at bryansmart.com (Bryan Smart)
Date: Tue, 16 Mar 2010 15:44:03 -0400
Subject: [netrek-dev] Audio-based Netrek Client
Message-ID: <26DA767D4A3B96479F633389CA1DD33826360B98E0@MAILSC004.mail.lan>

Hi Netrek dev community. I've joined the list to seek your advice. This is a fairly long post, but I hope that you will find the situation novel and the concept interesting.

I've been programming for about 20 years. I'm also blind. For those of you that aren't familiar with how that could be possible, many blind people use a class of software called a screen reader to translate a visual interface in to synthesized speech or Braille. Anyway, while I've programmed for a while professionally, one of my personal areas of interest are alternative user interfaces. The reasons for that interest are most likely quite obvious. A good way to experiment with these concepts has been to create computer games for blind users. Generically, these are now called audio games by our community. I know...screen readers, audio games...we need flashier terms. *smile*

The first audio games were specialized systems. A program was written specifically to convey all information directly through sound cues and synthesized speech. There are lots of simple games possible with that approach. Basically, the main difference between those games and a simple game with a visual interface is that the computer either reads all prompts, or describes the current situation.

After a few of those were made, the next stage was to determine how much of the presentation of the situation could be communicated with just audio. The most successful project from this stage was a project called Shades of Doom (Nothing to do with ID's Doom). This game used surround sound audio to allow someone to hear their environment while wearing headphones. Techniques used here included being able to hear footsteps echo from walls (so based on the echo delay, you can hear how close you are), hearing emphasized wind noises to indicate tunnels and passages (so people know when they have reached a fork in a hall, for example), and hearing cues to indicate equipment and power-ups that are on the ground. Speech still needs to be used to do things like describe an item once the player finds it, but the surround sound presentation greatly enhances the feel of being in a virtual space, and conveys detail that wouldn't be possible with just speech.

The most recent stage of this work has been to move beyond single-player and specialized games, and apply these concepts to mainstream games. One reason for that is to give blind players more people to play against than just other blind people. However, the cool technical aspect to it is that the audio client/blind client is just a different way of representing the game's interface. The best example of this so far has been a project to create an accessible version of the Quake client. This has worked out well. Sight is a higher bandwidth sense, but, we've been able to layer enough distinctive audio cues so that a blind player has enough information to navigate and avoid obstacles, hear the position and movement of other players and equipment, and target them. That has proven to be a really popular project.

A problem with that project, though, is that I think that we shot too high. There is so much audio information that you almost need to train people to be able to pick it all out at once and respond to it reflexively. Many players are dedicated, and have become very good at Audio Quake, but it is profoundly difficult for new users to jump in and start fragging.

So, this brings me to why I'm writing to you all. I think that an accessible (to the blind), client for Netrek would be a great experiment. I have some ideas regarding how I'll make everything work, but, being blind myself, I haven't played, nor can I use, the existing clients, so I'll be learning to play as I develop. That's how it went with Quake, though, so I don't imagine that it will be that bad.

Some aspects of the game, I can simply translate directly to audio. For example, instead of a top-down visual perspective on the map, I can use a first-person audio perspective. Instead of seeing a ship to your left, you'll hear the sound of a ship's engine to your left. If they fire a torpedo that streaks by you, you'll hear the torpedo streak by. I can make other positional sounds for planets, bases, etc. I don't imagine that this will cause any problems. I can, of course, add keyboard commands to speak the status of things like fuel level, position, etc.

However, there are some parts to the game that, no matter how hard I try, won't be completely balanced.

For example, one big problem that has come up when creating strategy games is that it is difficult for most blind users to get a quick overview of a complete map. This makes it difficult to provide them with ways to make decisions about where they should go, the status and arrangement of resources, etc. There are a few ways to partially overcome this problem, but they are far from perfect.

The first is that, instead of a map, I present them with a type of data view that shows all ships, planets, bases, etc, along with info about each. I provide keyboard commands to sort/refine this information. They can, for example, switch to showing only planets, only bases, only fed/rom/klingon objects, sort based on distance, number of armies, etc. This will permit strategy, but there is no way that they can take this info in as fast as looking at the galactic map.

Second, I can't think of a good way to make an accessible way of targeting an enemy with weapons, tractor beams, pressors, etc. I thought that I could turn on a targeting mode where they have a target ping that can be moved around their perspective. If the ping is moved ahead and to the left, for example, shooting a torpedo would fire it along that heading. It would be profoundly difficult to aim this way, though, so they'd be at a profound disadvantage.

Another approach would be to provide an automatic targeting feature, but there would need to be some sort of skill or limitation of that in order to keep it fair. I thought that either a constant probability could be set, or else the targeting accuracy would depend on a condition like the damage level of the computer or something. For the fixed probability, the software could compute a perfect heading, and then randomize it by something like 20%. It occurs to me, though, that even perfect targeting for something like a torpedo at launch time is no guaranty that the target won't dodge or something.

I know, from reading up on Netrek, though, that this would bring the accessible client in to cyborg territory. If someone came on a game with the accessible client, I wouldn't want the cyborg advantage such that people would feel like it was cheating.

Of course, it might be that I won't be able to figure out ways to help a blind player respond fast enough to the limitations in order to sufficiently compete against sighted players. If that happens, I would need to make a modified server that would only accept connections from the accessible client.
I'd prefer not to go this way, but, if I did, the first thing that I'd want to change is the speed of the game. Is there a central place in the server code that controls the rate of frame advance in the game? It is also possible that the server doesn't manage time that way (haven't looked at the server code yet). I'd like to do something like increase the time between frames by some factor like 4X, for example. Didn't see a config option for game speed, so I'm guessing that I'd need to recompile my own version of the server to make that happen.

OK. I think that this gives a good overview of the basics of what I'd like to do. Before I start going too deep with other ideas, I'd appreciate hearing feedback to know of any problems or other considerations that you all can think of, given your detailed experience with the system and code.

Thanks.

Bryan


From netrek at gmail.com  Tue Mar 16 17:54:55 2010
From: netrek at gmail.com (Zachary Uram)
Date: Tue, 16 Mar 2010 18:54:55 -0400
Subject: [netrek-dev] Audio-based Netrek Client
In-Reply-To: <26DA767D4A3B96479F633389CA1DD33826360B994A@MAILSC004.mail.lan>
References: <26DA767D4A3B96479F633389CA1DD33826360B994A@MAILSC004.mail.lan>
Message-ID: <ecfa260c1003161554h5c87deaasad95430840bd38d8@mail.gmail.com>

Hi Bryan,

What an interesting post! This Quake Audio client sounds really cool.
Netrek is a more difficult game to pick up with a steeper learning
curve to master the basics compared to some other games. However since
the learning curve for sight challenged players is already rather
high, maybe this won't seem any worse or perhaps be a bit easier to
get accustomed to than the Quake Audio which you said suffered from
having to convey a very high density of information at any time. In
netrek the top half of the screen is broken into two halves. The left
half is the tactical where you do close quarters combat (dogfighting)
and can only see a limited number of ships and planets, and the right
half is the galactic where one can see all planets and players' ships'
positions. Are blind users accustomed to having to memorize a good bit
of information when playing games? If so I thought maybe you could
tell them the position of the enemy planets and their planets
(involving 3rd space planets is not really essential) or setup a macro
so that when you press it the names of the planets closest to you in a
row (or a circle or column or whatever) could be quickly read off
right to left or whatever convention you think is best. When their
ship approaches a planet the user can be told the name of the planet,
whether it is an agri, fuel, repair or regular planet, and how many
armies it has. I would be glad to help out in anyway I can.

By the way, one of the list members, James Cameron, has been working
on a Python client and I noticed there is a Python Braille API library
called python-brlapi:
http://packages.debian.org/sid/python-brlapi

I also found a Speech Braille Server API for conveying sounds which
you may find useful:
http://portal.beam.ltd.uk/xvil/sbserver_api.html

Regards,
Zach

<>< http://www.fidei.org ><>


From bryansmart at bryansmart.com  Tue Mar 16 18:44:13 2010
From: bryansmart at bryansmart.com (Bryan Smart)
Date: Tue, 16 Mar 2010 19:44:13 -0400
Subject: [netrek-dev] Audio-based Netrek Client
In-Reply-To: <ecfa260c1003161554h5c87deaasad95430840bd38d8@mail.gmail.com>
References: <26DA767D4A3B96479F633389CA1DD33826360B994A@MAILSC004.mail.lan>
	<ecfa260c1003161554h5c87deaasad95430840bd38d8@mail.gmail.com>
Message-ID: <26DA767D4A3B96479F633389CA1DD33826360B99D9@MAILSC004.mail.lan>

Hi Zach.

A Python client would be good to use as a code base for an accessible client.

I use OSX most of the time now, and had a look at MacTrek. That client is object oriented, and is patterned as model view controller, so I thought I could just rip out the view and substitute kind of an audio view of sorts. Thought that would be the best way to do what I want without having to write a whole new client from scratch, and/or ripping out lots of pieces from a non-oo cllient.

However, most blind users are on Windows. Audio Quake is cross-platform, and it would be good if this could be, also. I know of some cross-platform speech libraries for Python, and PyGame would handle most of the type of audio support that I'd need.

So, the tactical view I'd present as first-person audio, and I'd present the galactic as a talking and sortable table.

However, what do you think about the targeting question?

I found James's Python client with Google just now. Hopefully, it is fairly modular, so I can strip out the visual parts. I'd leave them in, but the built-in UI, articularly if its custom-drawn, won't work with a screen reader, anyway.

I saw that his Python client also hasn't been updated in almost 2 years. Is it pretty much complete?

Bryan

-----Original Message-----
From: Zachary Uram [mailto:netrek at gmail.com] 
Sent: Tuesday, March 16, 2010 6:55 PM
To: Netrek Development Mailing List
Cc: Bryan Smart
Subject: Re: [netrek-dev] Audio-based Netrek Client

Hi Bryan,

What an interesting post! This Quake Audio client sounds really cool.
Netrek is a more difficult game to pick up with a steeper learning curve to master the basics compared to some other games. However since the learning curve for sight challenged players is already rather high, maybe this won't seem any worse or perhaps be a bit easier to get accustomed to than the Quake Audio which you said suffered from having to convey a very high density of information at any time. In netrek the top half of the screen is broken into two halves. The left half is the tactical where you do close quarters combat (dogfighting) and can only see a limited number of ships and planets, and the right half is the galactic where one can see all planets and players' ships'
positions. Are blind users accustomed to having to memorize a good bit of information when playing games? If so I thought maybe you could tell them the position of the enemy planets and their planets (involving 3rd space planets is not really essential) or setup a macro so that when you press it the names of the planets closest to you in a row (or a circle or column or whatever) could be quickly read off right to left or whatever convention you think is best. When their ship approaches a planet the user can be told the name of the planet, whether it is an agri, fuel, repair or regular planet, and how many armies it has. I would be glad to help out in anyway I can.

By the way, one of the list members, James Cameron, has been working on a Python client and I noticed there is a Python Braille API library called python-brlapi:
http://packages.debian.org/sid/python-brlapi

I also found a Speech Braille Server API for conveying sounds which you may find useful:
http://portal.beam.ltd.uk/xvil/sbserver_api.html

Regards,
Zach

<>< http://www.fidei.org ><>


From quozl at us.netrek.org  Tue Mar 16 22:00:20 2010
From: quozl at us.netrek.org (James Cameron)
Date: Wed, 17 Mar 2010 14:00:20 +1100
Subject: [netrek-dev] Audio-based Netrek Client
In-Reply-To: <26DA767D4A3B96479F633389CA1DD33826360B99D9@MAILSC004.mail.lan>
	<ecfa260c1003161554h5c87deaasad95430840bd38d8@mail.gmail.com>
	<26DA767D4A3B96479F633389CA1DD33826360B994A@MAILSC004.mail.lan>
Message-ID: <20100317030020.GI23034@us.netrek.org>

G'day Bryan,

Yes, I find the situation novel and the concept interesting, but I've an
existing sighted community to protect and nurture, so I lack the time to
become directly involved in your project idea.

I've done technical work for the disabled population in Australia, some
of it can be found at http://quozl.us.netrek.org/tad/ ... so I've a fair
idea of what you are up against.

Netrek could certainly be cast into an audio format, either as a side on
two dimensional space (like the Doom or Quake you mentioned, with the
player positioned within the space), or if suitable multi-channel audio
equipment was available as a two dimensional space with axis
perpendicular to the player, and the player outside the space on a third
axis.

A sighted player uses peripheral and near field vision for parallel
assessment of object locations.

Object positioning for blind players could be presented using one of
those pixel line devices, when the object is selected from a list.

An automatic targeting feature would either not be fair, or would not be
effective.  The latter is the most likely, in my opinion.  Effectiveness
is destroyed by dodging, and network latency.

Yes, the simulation frame rate is controlled in ntserv/daemon.c, and we
had a configuration option not so long ago that allowed this rate to be
varied in a way that would vary the apparent physics of the game.

The netrek-client-pygame is not in model view controller pattern, so
you'll have a hard time isolating the view components.  Not impossible,
just hard.  The client is updated about weekly at the moment; you must
examine the darcs source repository for updates.  The tar.gz releases
are very infrequent.

-- 
James Cameron
http://quozl.linux.org.au/


From billbalcerski at gmail.com  Wed Mar 17 08:12:28 2010
From: billbalcerski at gmail.com (Bill Balcerski)
Date: Wed, 17 Mar 2010 09:12:28 -0400
Subject: [netrek-dev] Objection to server patch: *asstorp modifiers
Message-ID: <45ab86181003170612x27f46525j3a96114f708ea4cd@mail.gmail.com>

Recently a patch has been added to the netrek-server repository with the
following description:

 * asstorp_modifiers
 Add multipliers to torp cost for asstorping. Affects fuel, etemp, and
 wtemp cost of firing rear torpedoes. Contributed by Ben Dehner, 2nd
 March 2010.

To summarize what the patch does, it adds a sysdef controllable option
(default: standard bronco settings, no change) to add multiplier costs to
photon torpedo fuel cost, wtemp cost, and a new etemp cost to firing photon
torpedoes depending on the angle of the torpedo.

My problem is this: it's too complex.  Great dogfighters know the exact fuel
cost of torpedoes and phasers.  The new patch adds a scaling cost to both
fuel, wtemp and etemp for torpedoes fired outside of roughly a 90 degree
forward arc of your ship heading (45 degrees to the left and 45 degrees to
the right).  The formula is complex enough that one will not be able to be
able to know the fuel cost before firing torpedoes outside of this arc.
Furthermore, the server does not communicate with the client what the
settings are for the multiplier costs, so the client has no way of even
estimating what the cost would be.  This is bad game design.  Netrek is
complex enough as it is.  New features like this would break dogfighting by
making it horribly complex, not to mention punish good dogfighting practices
like shooting sideways while dodging.

The way the new torp/wtemp/etemp cost is determined is as follows: The
formula for calculating cost first checks angle between torp and ship (this
number can range between 0 and 180 degrees).  If the angle is less than
roughly 45 degrees, there is no penalty.  If the angle is between roughly 45
and 135 degrees (side fired torps), there is a medium penalty in the form of
a first multiplier.  If the angle is greater than roughly 135 degrees (rear
fired torps), there is a large penalty in the form of a first multiplier.  A
second multiplier is then calculated, based on the sysdef multiplier setting
for fuel/etemp/wtemp, your ship speed (the faster your ship the larger this
term) and the first multiplier from torpedo angle.  This second multiplier
is then multiplied by original fuel/etemp/wtemp cost.

Yuk.

I can't be the only one who finds this objectionable.  "But it can be turned
off and defaults to off" some people might argue.  Just because it can be
turned off, and is off, doesn't mean it is worth including in the code.  In
fact I would argue this feature does way more harm than good by obfuscating
game play and adding an unnecessary penalty to good players.  Adding etemp
to firing weapons, really?  How about adding code that turns the planets
into Pokemon and rewarding us when we collect them all.  That would make
about as much sense as this patch.  I vote for removal from the repository.

Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20100317/34e61c0d/attachment.htm 

From netrek at gmail.com  Wed Mar 17 08:32:07 2010
From: netrek at gmail.com (Zachary Uram)
Date: Wed, 17 Mar 2010 09:32:07 -0400
Subject: [netrek-dev] Objection to server patch: *asstorp modifiers
In-Reply-To: <45ab86181003170612x27f46525j3a96114f708ea4cd@mail.gmail.com>
References: <45ab86181003170612x27f46525j3a96114f708ea4cd@mail.gmail.com>
Message-ID: <ecfa260c1003170632s59ec429al48791f95e6200938@mail.gmail.com>

Bill raises some valid points. I am also concerned this will lead to
undesirable behaviour such as newbies and semi-clue just deciding to
not even engage rather than risk a penalty. For example if you are
defending a planet alone versus carrier + escort and you have
reinforcements coming it is often possible to slow then down by
asstorping as you ever so slowly move back from front of planet giving
your teammates time to advance and assist. Also there are other
scenarios such as when you are escorting a carrier and your only way
to stop the SC ogger is by firing sideways. The non-intuitive nature
of the costs is also problematic as Bill mentioned. I fear this could
lead to an even wore situation where instead of the player engaging,
albeit via buttorping, they just run away and don't engage at all, and
wait for an 'ideal' (in their view) scenario.

Zach

<>< http://www.fidei.org ><>


From bryansmart at bryansmart.com  Wed Mar 17 15:20:58 2010
From: bryansmart at bryansmart.com (Bryan Smart)
Date: Wed, 17 Mar 2010 16:20:58 -0400
Subject: [netrek-dev] Audio-based Netrek Client
In-Reply-To: <20100317030020.GI23034@us.netrek.org>
References: <26DA767D4A3B96479F633389CA1DD33826360B99D9@MAILSC004.mail.lan>
	<ecfa260c1003161554h5c87deaasad95430840bd38d8@mail.gmail.com>
	<26DA767D4A3B96479F633389CA1DD33826360B994A@MAILSC004.mail.lan>
	<20100317030020.GI23034@us.netrek.org>
Message-ID: <26DA767D4A3B96479F633389CA1DD33826360B9CAB@MAILSC004.mail.lan>

Hi James. Thank you for taking the time to respond.

Oh yes; I realize that most of us already have allocated our thin time resources. I fully expect to be handling any coding work on my own. Of you, and the list, I'm simply seeking advice, so that I spend my time productively, rather than trying something that I would know to be a bad idea if I had additional experience with the game.

Particularly when considering your remarks about targeting, I'm beginning to feel that I will almost certainly need to use a modified server. If an automatic targeting calculation wouldn't be affective client-side, then I'd need to modify the server so that torpedoes have a homing function. The simple way that I've made smart/tracking projectiles/missiles work in other games is to have them always turn toward their target, but to restrict them with a maximum turning rate. That way, they're guided, and will hit someone that isn't avoiding, or is sitting stationary, but will only occasionally hit someone that is actively avoiding. Changing the way that torpedoes work would absolutely require me to change the server, unless this could be implemented as a configurable server option. I don't know too much about how server options work yet, or how/if clients are notified about game-specific mods yet, so don't know how practical that approach would be.

As I have read through the guides, I've found places where people talk about cyborg clients. It seems like these clients do assist with aiming/targeting, unless I've misread. If targeting from a client was impractical, then I don't understand how cyborgs can be a bother in that regard.

In Mactrek, there is a "l" key that seems to lock on to the nearest ship. Perhaps that is only for tracking/viewing purposes?

I don't mean to dismiss your advice about targeting. I'm just trying to be sure that all options are out before I add server modifications to client modifications on the to-do list. *smile*

If I must modify the server, also, then this means that Audiotrek/Sonictrek/what-ever will end up being a separate game. There is still value in that case, since I'm not having to start from scratch, but I'd hoped that I could find a way to have an audio client work with the regular Netrek.

If I do need to fork off in to another project, do you think that I should consider one of the Netrek variants? I saw one called Paradise. I vaguely understand that there are some disagreements over how many ship types are available in that one, but, if I'm forking, I would have the option to restrict/customize that stuff, anyway. My reasoning for considering a variant like that is that it might give me a larger inventory of features to call upon, even if I strip some away in the final version of what I use.

Will your client work with Paradise or other variants? Looking through your code, I think that I saw a reference in your ship capabilities module to the Galaxy cruiser that I remember is part of Paradise. Remember that, at least for now, I'm looking at the old tarball of our client. I'll get the newer version that you referenced today.

Finally, one technical question about your client. The way that I'll probably begin work is to try to strip away as much of the high level code as possible until I'm left with the code that manages communication with the server. Looks like you keep most of that in client.py. Its also easy to see how you trap key presses in the main module, and how those simply call functions that transmit the appropriate message to the server.

It isn't, however, obvious to me how events from the server are dispatched inside your code. For example, if some game object moves, or if someone sends a message, then client.py must switch control to a function in your client that responds to that like an event handler. I can't find these handlers, though.

Lastly, is the Netrek client/server protocol documented somewhere outside of reverse-engineering the code? I've Googled quite a bit, but can't find it, if its out there. If it isn't, then I'm probably much better off building on your client.py module, rather than trying to create something myself.

Thanks again for your experienced input.

Bryan

-----Original Message-----
From: netrek-dev-bounces at us.netrek.org [mailto:netrek-dev-bounces at us.netrek.org] On Behalf Of James Cameron
Sent: Tuesday, March 16, 2010 11:00 PM
To: Netrek Development Mailing List
Subject: Re: [netrek-dev] Audio-based Netrek Client

G'day Bryan,

Yes, I find the situation novel and the concept interesting, but I've an existing sighted community to protect and nurture, so I lack the time to become directly involved in your project idea.

I've done technical work for the disabled population in Australia, some of it can be found at http://quozl.us.netrek.org/tad/ ... so I've a fair idea of what you are up against.

Netrek could certainly be cast into an audio format, either as a side on two dimensional space (like the Doom or Quake you mentioned, with the player positioned within the space), or if suitable multi-channel audio equipment was available as a two dimensional space with axis perpendicular to the player, and the player outside the space on a third axis.

A sighted player uses peripheral and near field vision for parallel assessment of object locations.

Object positioning for blind players could be presented using one of those pixel line devices, when the object is selected from a list.

An automatic targeting feature would either not be fair, or would not be effective.  The latter is the most likely, in my opinion.  Effectiveness is destroyed by dodging, and network latency.

Yes, the simulation frame rate is controlled in ntserv/daemon.c, and we had a configuration option not so long ago that allowed this rate to be varied in a way that would vary the apparent physics of the game.

The netrek-client-pygame is not in model view controller pattern, so you'll have a hard time isolating the view components.  Not impossible, just hard.  The client is updated about weekly at the moment; you must examine the darcs source repository for updates.  The tar.gz releases are very infrequent.

--
James Cameron
http://quozl.linux.org.au/

_______________________________________________
netrek-dev mailing list
netrek-dev at us.netrek.org
http://mailman.us.netrek.org/mailman/listinfo/netrek-dev


From ahn at orion.netrek.org  Wed Mar 17 17:02:16 2010
From: ahn at orion.netrek.org (Dave Ahn)
Date: Wed, 17 Mar 2010 18:02:16 -0400
Subject: [netrek-dev] Audio-based Netrek Client
In-Reply-To: <26DA767D4A3B96479F633389CA1DD33826360B9CAB@MAILSC004.mail.lan>
References: <26DA767D4A3B96479F633389CA1DD33826360B99D9@MAILSC004.mail.lan>
	<ecfa260c1003161554h5c87deaasad95430840bd38d8@mail.gmail.com>
	<26DA767D4A3B96479F633389CA1DD33826360B994A@MAILSC004.mail.lan>
	<20100317030020.GI23034@us.netrek.org>
	<26DA767D4A3B96479F633389CA1DD33826360B9CAB@MAILSC004.mail.lan>
Message-ID: <20100317220216.GA27354@orion.netrek.org>

I don't actively follow netrek-dev, but this topic is sufficiently interesting
for me to comment upon if you wish to continue listening.

Netrek is a complex game.  There is simply too much visual information that is
viewed and assessed many times a second by a visual player, and much of that
information is relevant only in the context of positions and frames of
reference in the game.  While it may be possible to convey that information
through non-visual means, there can be a tremendous loss or misrepresentation
of that information in the process which can severely impact game play.

Because Netrek depends upon all players being subjected to the same playing
field, the only way for it to be fair for non-visual players is to either
restrict the game to only non-visual players or to augment the disadvantaged
group with unique advantages that both types of players agree are fair.  Note
that the disadvantaged group is not necessarily the non-visual players.

I think a key decision for you is whether or not it is your primary objective
to enable visual and non-visual players to play together in the same Netrek
server as it exists today.

If the answer is no, then you can folllow any or all of your own ideas to fork
and create a non-visual Netrek derivative.  If done well, this could be of
interest to all players regardless of their ability to see (visual players can
obviously use a non-visual client).

If the answer is yes, then I think you should focus on augmenting your
non-visual client so that non-visual players can be better team players, and
delegate fine-grained, individual control of the player's ship to AI (i.e.
borg).  In other words, the non-visual player should direct the ship's AI using
meta commands to attack, defend, or assist in the team's efforts in very
specific ways without having to specify the exact local position and frame of
reference information.

In Netrek, a great dogfighter with top-knotch skill but no clue is far less
useful than a poor dogfighter with strong galactic awareness and team-assisting
knowledge of where to be and what to do.  If you enable a non-visual player to
understand and act upon galactic and team information, then that player can
become effective.

Good luck.



From quozl at us.netrek.org  Thu Mar 18 00:34:33 2010
From: quozl at us.netrek.org (James Cameron)
Date: Thu, 18 Mar 2010 16:34:33 +1100
Subject: [netrek-dev] Audio-based Netrek Client
In-Reply-To: <26DA767D4A3B96479F633389CA1DD33826360B9CAB@MAILSC004.mail.lan>
References: <26DA767D4A3B96479F633389CA1DD33826360B99D9@MAILSC004.mail.lan>
	<ecfa260c1003161554h5c87deaasad95430840bd38d8@mail.gmail.com>
	<26DA767D4A3B96479F633389CA1DD33826360B994A@MAILSC004.mail.lan>
	<20100317030020.GI23034@us.netrek.org>
	<26DA767D4A3B96479F633389CA1DD33826360B9CAB@MAILSC004.mail.lan>
Message-ID: <20100318053432.GE8013@us.netrek.org>

G'day Bryan,

There is torpedo target tracking in the server.  Plasma torpedoes have a
level of tracking that is standard.  Ordinary torpedoes can probably
have this tracking turned on through configuration of ship parameters in
the etc/sysdef file.  I've not checked recently.  Enabling full tracking
on a ship (which can be done using "xtkill SLOT sA") generates torpedoes
that are useless for anything except random spraying.  They turn toward
the nearest enemy.

Changes to the server can be negotiated in the protocol using the
SP_FEATURE and CP_FEATURE packets.

The client key "l" sends a CP_PLAYLOCK packet to the server, which
causes the server to set flag PFPLOCK (not PFPLLOCK) and the ship
navigates towards the selected other ship.  Often used for docking to a
base.  Rarely used for locking on to a ship that you suspect may
cloak, since the lock is retained after cloak is begun.  Often used by
new players to target an enemy in a way that allows the enemy to most
rapidly kill them, since their vector is predictable and straight-on.

The same client key is also used when observing; it causes the observing
client to display the view as seen by the observed ship.  The
CP_PLAYLOCK packet is handled differently for server slots that
represent observing clients.

You should evaluate the code quality in Vanilla and Paradise before you
pick one based purely on available features.  We've worked hard to bring
many features into the Vanilla code, as selectable options.  I can't
give you an opinion on Paradise code quality.  I'm not aware of any
other actively used server source apart from these two projects.

No, my client does not currently work with Paradise, and avoids listing
Paradise servers obtained from the metaserver.

Regarding the technical question you had about how data from the server
is processed:

1.  client.py dispatches packets based on the packet type to server
packet handlers (they all start with SP_ and are in __init__.py),

2.  the server packet handlers then call into the model objects, such as
galaxy, ship, planet,

3.  the model objects call into the view objects, such as the ship and
planet sprites to update certain details,

4.  when the data from the server has apparently finished for the
moment, the view objects, or sprites, are redrawn on screen, in
PhaseFlight and descendent objects.

The constructor of the server packet handlers creates a hash or
dictionary which describes the packet lengths and handling function.
The functions contain packet decoders using python struct semantics.

You can find the pystruct stuff also in the server, in file
include/packets.h ... this file also answers your question about
protocol documentation; it's the best documentation we have, and it is
kept in the code for rather obvious reasons of synchronisation.

-- 
James Cameron
http://quozl.linux.org.au/


From chris.lukassen at gmail.com  Thu Mar 18 18:10:38 2010
From: chris.lukassen at gmail.com (Chris Lukassen)
Date: Fri, 19 Mar 2010 00:10:38 +0100
Subject: [netrek-dev] Audio-based Netrek Client
In-Reply-To: <mailman.1.1268931602.23142.netrek-dev@us.netrek.org>
References: <mailman.1.1268931602.23142.netrek-dev@us.netrek.org>
Message-ID: <405AA464-A01F-43AB-ABA7-6C726F7E6FD1@gmail.com>

> 
> In Mactrek, there is a "l" key that seems to lock on to the nearest ship. Perhaps that is only for tracking/viewing purposes?
> 

General lock function, it is in most clients. To come back to your previous post, you could indeed go in the painter class and turn it into a "speaker", the python client is a lot smaller and easier to digest though :-)
> 
> Lastly, is the Netrek client/server protocol documented somewhere outside of reverse-engineering the code? I've Googled quite a bit, but can't find it, if its out there.

There is a small description in the MacTrek developer guide, but the network layer is like dark magic, it's out there but only few have seen it in real life. I never managed to get UDP support running :-( there is also a java version which is not maintained actively but is cross platform and Object Oriented.

Good luck and this will be a very interesting project to see, ahum hear.

Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20100319/9a6e49db/attachment.htm 

From mrbax.nospam.2007 at gmail.com  Thu Mar 18 18:21:24 2010
From: mrbax.nospam.2007 at gmail.com (Michael Bax)
Date: Thu, 18 Mar 2010 16:21:24 -0700 (PDT)
Subject: [netrek-dev] Objection to server patch: *asstorp modifiers
In-Reply-To: <mailman.1.1268845202.29806.netrek-dev@us.netrek.org>
Message-ID: <844311297.53501268954484150.JavaMail.root@zm03.stanford.edu>

> Yuk.
> 
> I can't be the only one who finds this objectionable.

> I vote for removal from the repository.

I concur with vigour.

Michael


From netrek at gmail.com  Mon Mar 22 08:59:06 2010
From: netrek at gmail.com (Zachary Uram)
Date: Mon, 22 Mar 2010 09:59:06 -0400
Subject: [netrek-dev] Improving the netrek development community
Message-ID: <ecfa260c1003220659rf95b027l1c2253132a2a7d4a@mail.gmail.com>

Listened to a presentation on ways to destroy open source communities
and I think some of the points would benefit netrek. Here are my
notes. Reactions, thoughts? How can we go forward with building up the
netrek dev community?

Zach

Ten Ways to Destroy Your Community
by Josh Berkus

talk given at LCA2010

These are so powerful that any 3 should kill most development communities.

(whining)

1. difficult tools -
*  obscure build systems
*  limited license issue trackers

( setup official website -
  have it be down as often as it is up)

2. poisonous people who turn community against itself with
*  a few ppl who are there just to give you a hard time
*  considered primary cost of managing open source
*  a single poisonous person can wipe out a user community of hundreds
*  argue with them on public forums
*  launch into polemics
*  then ban them from the community by fiat
*  argue with them in other forums
*  after people step up and say "this is wrong" - allow them back on
the project and repeat...

3. prevent documentation
*  no code documentation
*  no user documentation
*  no project documentation
*  no contributor documentation
*  no site or release documentation
*  make sure no useful docs at all
*  if anyone asks for help ask them to reading the f**king manual.
*  if you must have documents give them a restrictive proprietary license

4. make your contributors feel excluded
*  don't let your contributors into the decision making process of the project
*  make sure the poisonous people attend the meetings
*  short notice online meetings

5. legalese - the longer and more complex the better!
*  change it every few months

6. bad liaison - who is the public face of your community
*  someone reclusive
*  find a developer with no friends who hates people
*  or find the busiest developer and make them the community liaison
*  have no liaison at all but keep an email account active

7. governance obfuscation
*  have governance so complicated that contributors can't figure out
how to participate
   3 principles:
    * decision making and elections should be extremely complex and lengthy
    * make it unclear what powers community officials and committees
actually have
    * make governance rules nearly impossible to change
*  have a community council and then don't give them any real power
   great way to create poisonous people
*  no decisions can be made without a super majority

8. screw around with licenses (psychological technique)
*  license ~= identity
*  keep changing the license of your project (GPL to BSD etc.)
*  don't make it easy for someone to fork the project on their own
*  spend a lot of time talking about changing the license without changing it

9. no outside committers
*  no matter how much code outsiders write *only* employees get to be committers
*  protect your core group of contributors
*  have no written rules on why or how someone gets to be a contributor

10. do nothing, be silent
*  this technique is the most powerful and effective and the easiest
*  don't answer questions
*  ignore emails
*  setup a separate email account/mailing list for feedback and ignore it

When I was at Sun we employed all of these techniques successfully.

Every community person you turn away now will save you that much work later.

Best ways to deal with poisonous people:
* Have a lot of documented processes and structure that is fair and accessible.
  Poisonous people will try to portray themselves as a victim to garner support.
* Have a community process for throwing someone off the project - a
community council
  that votes etc.

If people are not contributing on the community forums they do not
have the right
to speak. You must kick them out. Otherwise you have 1 person who is not doing
anything to contribute that is sucking up 20% of the communities online time.

Do not give trolls a voice.

Two main types of poisonous people:
* trolls looking for attention
* people interested in an issue tangential to your project

Don't give them a soapbox.

Losing community happens in days or weeks. Regaining community happens
over years.

Better to under promise and over deliver than vice versa.



<>< http://www.fidei.org ><>


From bryansmart at bryansmart.com  Mon Mar 22 11:06:01 2010
From: bryansmart at bryansmart.com (Bryan Smart)
Date: Mon, 22 Mar 2010 12:06:01 -0400
Subject: [netrek-dev] Audio-based Netrek Client
In-Reply-To: <20100318053432.GE8013@us.netrek.org>
References: <26DA767D4A3B96479F633389CA1DD33826360B99D9@MAILSC004.mail.lan>
	<ecfa260c1003161554h5c87deaasad95430840bd38d8@mail.gmail.com>
	<26DA767D4A3B96479F633389CA1DD33826360B994A@MAILSC004.mail.lan>
	<20100317030020.GI23034@us.netrek.org>
	<26DA767D4A3B96479F633389CA1DD33826360B9CAB@MAILSC004.mail.lan>
	<20100318053432.GE8013@us.netrek.org>
Message-ID: <26DA767D4A3B96479F633389CA1DD33826362C26B2@MAILSC004.mail.lan>

Hello James.

Thank you for your extremely detailed response! I've taken time to respond to be sure that I had a chance to investigate much of what you talked about, though I'm still following the threads.

I've come to the conclusion that, at minimum, people using the audio client won't be able to play on a typical public Netrek server. However, I'm now attempting to find ways to adapt game play without having to fork the server.

I'd appreciate an answer on the following from anyone. If I decide that a particular feature is necessary to play with the audio client, can that be easily added as a configurable option on the server? As an example, suppose that the audio client games will need torpedoes that support some degree of automatic tracking. People obviously wouldn't want that in standard games. If torpedo tracking were a configurable option (meaning that I can set it without having to edit source and recompile), would it play nice with the standard clients? If a standard client joined a standard game, they would be notified that the server was set to use torpedo tracking? As long as people are notified if special conditions are in affect, then adding special conditions like this shouldn't be a problem. Right?

Regarding the old speed setting in daemon.c, I might need that put back. *smile* Presenting map information in an audio client will be much slower, and so I'd need to be able to slow down games where audio clients are present.

A question, though. What was affected by that old setting? Slowing down the speed of the physics in the game is all fine (motion of ships, speed of torps, etc), but does it also hopefully scale down the other time-based elements in the game (army growth time, repair speed, bombing speed, cloak time, etc)? All of those would need to slow down for the entire game to run at a slower pace.

It seems like the clients have complete information about everything in the entire galaxy at once. If this is so, then there is probably some standard about how much should be revealed at any given time. Is it up to me as a client developer to restrict the tactical to a certain range, or to not allow players to know certain things about planets until they are close enough (some fog of war type situation)?

I have some questions about the protocol, but those aren't strictly related to the audio client, so I'll start another thread for that.

Bryan
 
-----Original Message-----
From: netrek-dev-bounces at us.netrek.org [mailto:netrek-dev-bounces at us.netrek.org] On Behalf Of James Cameron
Sent: Thursday, March 18, 2010 1:35 AM
To: Netrek Development Mailing List
Subject: Re: [netrek-dev] Audio-based Netrek Client

G'day Bryan,

There is torpedo target tracking in the server.  Plasma torpedoes have a level of tracking that is standard.  Ordinary torpedoes can probably have this tracking turned on through configuration of ship parameters in the etc/sysdef file.  I've not checked recently.  Enabling full tracking on a ship (which can be done using "xtkill SLOT sA") generates torpedoes that are useless for anything except random spraying.  They turn toward the nearest enemy.

Changes to the server can be negotiated in the protocol using the SP_FEATURE and CP_FEATURE packets.

The client key "l" sends a CP_PLAYLOCK packet to the server, which causes the server to set flag PFPLOCK (not PFPLLOCK) and the ship navigates towards the selected other ship.  Often used for docking to a base.  Rarely used for locking on to a ship that you suspect may cloak, since the lock is retained after cloak is begun.  Often used by new players to target an enemy in a way that allows the enemy to most rapidly kill them, since their vector is predictable and straight-on.

The same client key is also used when observing; it causes the observing client to display the view as seen by the observed ship.  The CP_PLAYLOCK packet is handled differently for server slots that represent observing clients.

You should evaluate the code quality in Vanilla and Paradise before you pick one based purely on available features.  We've worked hard to bring many features into the Vanilla code, as selectable options.  I can't give you an opinion on Paradise code quality.  I'm not aware of any other actively used server source apart from these two projects.

No, my client does not currently work with Paradise, and avoids listing Paradise servers obtained from the metaserver.

Regarding the technical question you had about how data from the server is processed:

1.  client.py dispatches packets based on the packet type to server packet handlers (they all start with SP_ and are in __init__.py),

2.  the server packet handlers then call into the model objects, such as galaxy, ship, planet,

3.  the model objects call into the view objects, such as the ship and planet sprites to update certain details,

4.  when the data from the server has apparently finished for the moment, the view objects, or sprites, are redrawn on screen, in PhaseFlight and descendent objects.

The constructor of the server packet handlers creates a hash or dictionary which describes the packet lengths and handling function.
The functions contain packet decoders using python struct semantics.

You can find the pystruct stuff also in the server, in file include/packets.h ... this file also answers your question about protocol documentation; it's the best documentation we have, and it is kept in the code for rather obvious reasons of synchronisation.

--
James Cameron
http://quozl.linux.org.au/

_______________________________________________
netrek-dev mailing list
netrek-dev at us.netrek.org
http://mailman.us.netrek.org/mailman/listinfo/netrek-dev


From bryansmart at bryansmart.com  Mon Mar 22 11:35:01 2010
From: bryansmart at bryansmart.com (Bryan Smart)
Date: Mon, 22 Mar 2010 12:35:01 -0400
Subject: [netrek-dev] Understanding Netrek Protocol
Message-ID: <26DA767D4A3B96479F633389CA1DD33826362C26E2@MAILSC004.mail.lan>

Hi.

I'm attempting to learn the type of messages and expected data that is part of client/server communication by reviewing packets.h from the server code.

I think that I'm missing something in the formatting of the file. I see constants that are reserved to indicate message identifiers, and I see the structs that indicate the format of different message blocks, but it isn't always clear what message block is sent with what message.

I'm using James Cameron's Python client as a guide, so don't need to write code for sending/receiving and extracting packets from messages, but it would be good to know enough about what is in packets.h so that I could figure out what data should be included with each message.

Here is an example:

packets.h gives this constant for a torp info message

#define SP_TORP_INFO	5		/* torp status */

Scrolling down further, I find:

struct torp_info_spacket { /* SP_TORP_INFO py-struct "!bbbxhxx" #5 */
    char  type;
    char  war;
    char  status;	/* TFREE, TDET, etc... */
    char  pad1;		/* pad needed for cross cpu compatibility */
    short tnum;
    short pad2;
};

In the first line, I think that the #5 means that the struct is associated with message 5, which is the SP_Torp_Info message.

However, what is "!bbbxhxx"?

It looks like a lot of information is sent with this packet. There aren't comments to know what each field means. Some, like type and war, don't seem clear at all to me. Type of what? War means what?

And lines like

    char  status;	/* TFREE, TDET, etc... */


I think TDET means that the torp was detonated, or does it just mean that it detonated, but it doesn't necessarily mean it was self-detonated. Maybe a client doesn't care.

What is TFREE? Can't think of how free applies to a torp.

Then, it says etc??? *shrug* There are other undocumented statuses? Maybe all statuses are enumerated somewhere, so they don't need to be here.

When I look in James's code, his handler for this message is defined like:

    def sp_torp_info(self, war, status):

So war and status obviously come from the fields in the struct. Where is type, though?

And there are three other unclearly named fields in the struct that aren't arguments to this handler. Maybe they don't contain data, and are used as some part of the packet sequencing? Perhaps James isn't sure what these are for, so just hasn't included them when he updates torps?

I suspect that I have some general misconceptions here, so if someone helps me clear them up, it will probably make everything else much more clear.

Thanks
Bryan


From quozl at us.netrek.org  Mon Mar 22 16:56:30 2010
From: quozl at us.netrek.org (James Cameron)
Date: Tue, 23 Mar 2010 08:56:30 +1100
Subject: [netrek-dev] Audio-based Netrek Client
In-Reply-To: <26DA767D4A3B96479F633389CA1DD33826362C26B2@MAILSC004.mail.lan>
References: <26DA767D4A3B96479F633389CA1DD33826360B99D9@MAILSC004.mail.lan>
	<ecfa260c1003161554h5c87deaasad95430840bd38d8@mail.gmail.com>
	<26DA767D4A3B96479F633389CA1DD33826360B994A@MAILSC004.mail.lan>
	<20100317030020.GI23034@us.netrek.org>
	<26DA767D4A3B96479F633389CA1DD33826360B9CAB@MAILSC004.mail.lan>
	<20100318053432.GE8013@us.netrek.org>
	<26DA767D4A3B96479F633389CA1DD33826362C26B2@MAILSC004.mail.lan>
Message-ID: <20100322215630.GC25930@us.netrek.org>

On Mon, Mar 22, 2010 at 12:06:01PM -0400, Bryan Smart wrote:
> I'd appreciate an answer on the following from anyone. If I decide
> that a particular feature is necessary to play with the audio client,
> can that be easily added as a configurable option on the server?

Yes.

The client would have to indicate to the server that it desires use of a
configurable option before the server would begin to use it for that
client.

We handle this with CP_FEATURE and SP_FEATURE packet exchanges.

> As long as people are notified if special conditions are in affect,
> then adding special conditions like this shouldn't be a problem.
> Right?

I don't set policy for servers other than my own, but I think it would
be unwise to hide the special features.  I'd prefer there be a way for
people to find out, even if it is through the message of the day.

> A question, though. What was affected by that old setting? Slowing
> down the speed of the physics in the game is all fine (motion of
> ships, speed of torps, etc), but does it also hopefully scale down the
> other time-based elements in the game (army growth time, repair speed,
> bombing speed, cloak time, etc)? 

Yes, it slows or speeds everything, since they are all based on the same
timer.

> It seems like the clients have complete information about everything
> in the entire galaxy at once.

Nearly true.  The information is held back by the server or manipulated,
according to game design.

For instance, information about planet army counts are not sent until a
team has orbited a planet.  Position information about ships is sent
very slowly and somewhat randomised if they are cloaked.  Position
information about ships is sent slowly if they are off tactical.
Position information about torps is not sent at all if they are off
tactical.

> If this is so, then there is probably some standard about how much
> should be revealed at any given time. Is it up to me as a client
> developer to restrict the tactical to a certain range, or to not allow
> players to know certain things about planets until they are close
> enough (some fog of war type situation)?

Yes, client developer is responsible for this, but generally if the
server tells you then you may as well tell the user.  It isn't always
useful though, and it can easily hinder.

As an example, if an enlarged tactical is provided, the result is that
torpedos launched from a ship off tactical appear out of nowhere when
they cross the tactical boundary.  Also, ships have a jerky movement off
tactical.

As another example, if cloaked ships are shown, they occupy a single
location with an incorrect heading, then jerk to a new location.

-- 
James Cameron
http://quozl.linux.org.au/


From quozl at us.netrek.org  Mon Mar 22 20:05:37 2010
From: quozl at us.netrek.org (James Cameron)
Date: Tue, 23 Mar 2010 12:05:37 +1100
Subject: [netrek-dev] Understanding Netrek Protocol
In-Reply-To: <26DA767D4A3B96479F633389CA1DD33826362C26E2@MAILSC004.mail.lan>
References: <26DA767D4A3B96479F633389CA1DD33826362C26E2@MAILSC004.mail.lan>
Message-ID: <20100323010537.GY25930@us.netrek.org>

G'day Bryan,

On each struct line, the comment string that contains "py-struct" is for
automatic source code generation of the Python code, using the C code as
input.  You can find more information on the format character string
"!bbbxhxx" by reading the Python struct module documentation at:

http://docs.python.org/library/struct.html

The format string is the Python way of describing the data structure,
and the lines that are inside the braces of the C data structure define
the structure for C programmes.

The "char type" at the start of every packet does not form part of the
packet data, but is instead used to differentiate the packet from other
packets.  Line 117 of include/packets.h says this.

The exact content of every packet is not currently documented, but I'm
happy to add that documentation when it is needed.

The usual way to understand the packet content is to play the game whil
reading a packet trace.  The Python client has a --dump-server option
for that.

"war" is probably a bit mask of teams the torpedo is hostile toward.

"status" is one of the predefined status codes for torpedos, you can
find a list in another include file.  Search for TFREE in struct.h to
see the state explanations.  It would be redundant to add the
explanations to the packet structure.

TFREE means the torpedo array entry is empty, it represents no torpedo.

I didn't design these structures, by the way.

Structure members labelled pad are for aligning the data stream to four
byte boundaries for network and CPU efficiency.

-- 
James Cameron
http://quozl.linux.org.au/


From quozl at us.netrek.org  Mon Mar 22 21:27:31 2010
From: quozl at us.netrek.org (James Cameron)
Date: Tue, 23 Mar 2010 13:27:31 +1100
Subject: [netrek-dev] Objection to server patch: *asstorp modifiers
In-Reply-To: <844311297.53501268954484150.JavaMail.root@zm03.stanford.edu>
References: <mailman.1.1268845202.29806.netrek-dev@us.netrek.org>
	<844311297.53501268954484150.JavaMail.root@zm03.stanford.edu>
Message-ID: <20100323022731.GZ25930@us.netrek.org>

Thank you all for your opinion, however it is my policy as development
dictator to judge all patches on their technical merits while retaining
compatibility.

This patch is certainly unbalancing, but we have plenty of other game
options that are as much or even more unbalancing.

If you encounter a server with the feature enabled, you can talk with
the server owner about it.

-- 
James Cameron
http://quozl.linux.org.au/


From quozl at us.netrek.org  Tue Mar 23 00:07:44 2010
From: quozl at us.netrek.org (James Cameron)
Date: Tue, 23 Mar 2010 16:07:44 +1100
Subject: [netrek-dev] Improving the netrek development community
In-Reply-To: <ecfa260c1003220659rf95b027l1c2253132a2a7d4a@mail.gmail.com>
References: <ecfa260c1003220659rf95b027l1c2253132a2a7d4a@mail.gmail.com>
Message-ID: <20100323050744.GA18231@us.netrek.org>

On Mon, Mar 22, 2010 at 09:59:06AM -0400, Zachary Uram wrote:
> Listened to a presentation on ways to destroy open source communities
> and I think some of the points would benefit netrek.

If anybody else would like to catch this session from LCA 2010, here's
the link to the conference audio and video ...

http://www.r2.co.nz/20100118/

... and to the main auditorium session ...

http://2009.r2.co.nz/20100118/mfc-m-2.htm

> (whining)

We get a fair bit of that.
ENOPATCH.

> 1. difficult tools -
> *  obscure build systems
> *  limited license issue trackers

What, like Launchpad?  That's one reason I'm using ditz.  Launchpad is
okay if you've got low latency.

> 2. poisonous people who turn community against itself with
> *  a few ppl who are there just to give you a hard time

Clue.

> *  considered primary cost of managing open source
> *  a single poisonous person can wipe out a user community of hundreds
> *  argue with them on public forums
> *  launch into polemics
> *  then ban them from the community by fiat
> *  argue with them in other forums
> *  after people step up and say "this is wrong" - allow them back on
> the project and repeat...

Heh.

> 3. prevent documentation
> *  no code documentation
> *  no user documentation
> *  no project documentation
> *  no contributor documentation
> *  no site or release documentation
> *  make sure no useful docs at all
> *  if anyone asks for help ask them to reading the f**king manual.
> *  if you must have documents give them a restrictive proprietary license

We're trying to do documentation, but only when it is clearly needed.

> 4. make your contributors feel excluded
> *  don't let your contributors into the decision making process of the project
> *  make sure the poisonous people attend the meetings
> *  short notice online meetings

Or have no meetings.  At all.  Ever.

> 5. legalese - the longer and more complex the better!
> *  change it every few months

We're not guilty on that one, although the Trouble with RSA was a
community killer for a while.

> 6. bad liaison - who is the public face of your community
> *  someone reclusive

Me!

> *  find a developer with no friends who hates people

Me!

> *  or find the busiest developer and make them the community liaison

Oh, me!

> *  have no liaison at all but keep an email account active

We're not guilty.  Or are we; cow at netrek.org goes where?

> 7. governance obfuscation
> *  have governance so complicated that contributors can't figure out
> how to participate
>    3 principles:
>     * decision making and elections should be extremely complex and lengthy
>     * make it unclear what powers community officials and committees
> actually have
>     * make governance rules nearly impossible to change

We nearly achieved this with the NIT.

> *  have a community council and then don't give them any real power
>    great way to create poisonous people
> *  no decisions can be made without a super majority

Heh.

> 8. screw around with licenses (psychological technique)
> *  license ~= identity
> *  keep changing the license of your project (GPL to BSD etc.)
> *  don't make it easy for someone to fork the project on their own
> *  spend a lot of time talking about changing the license without changing it

Not guilty.  The license is adequate for forking.

> 9. no outside committers
> *  no matter how much code outsiders write *only* employees get to be committers
> *  protect your core group of contributors
> *  have no written rules on why or how someone gets to be a contributor

Not guilty.  We're using a distributed repository model, and the master
tends to take everything as long as it doesn't break something.

> 10. do nothing, be silent
> *  this technique is the most powerful and effective and the easiest
> *  don't answer questions
> *  ignore emails
> *  setup a separate email account/mailing list for feedback and ignore it

We're fairly good at these.

> Two main types of poisonous people:
> * trolls looking for attention
> * people interested in an issue tangential to your project

We sometimes hear from people who might meet those definitions.

-- 
James Cameron
http://quozl.linux.org.au/


From quozl at us.netrek.org  Wed Mar 24 05:31:11 2010
From: quozl at us.netrek.org (James Cameron)
Date: Wed, 24 Mar 2010 21:31:11 +1100
Subject: [netrek-dev] netrek-client-pygame-0.5 released
Message-ID: <20100324103111.GA8594@us.netrek.org>

A Netrek client, using pygame, for any operating system supported by
python and pygame, including Microsoft Windows, MAC OS X, and Linux.

netrek-client-pygame 0.5 was released, with huge changes since 0.4,
including messaging, RCDs, introductory documentation, and flexible
screen resolution.

http://quozl.us.netrek.org/netrek-client-pygame/ has screenshots.

http://quozl.linux.org.au/netrek-client-pygame/
b346e3bdec6167811fce2eb62af73119  netrek-client-pygame-0.5.tar.gz

-- 
James Cameron
http://quozl.linux.org.au/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: Digital signature
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20100324/e584d5c0/attachment.pgp 

From mark at mark.mielke.cc  Wed Mar 24 10:28:17 2010
From: mark at mark.mielke.cc (Mark Mielke)
Date: Wed, 24 Mar 2010 11:28:17 -0400
Subject: [netrek-dev] netrek-client-pygame-0.5 released
In-Reply-To: <20100324103111.GA8594@us.netrek.org>
References: <20100324103111.GA8594@us.netrek.org>
Message-ID: <4BAA2F91.9080402@mark.mielke.cc>

On 03/24/2010 06:31 AM, James Cameron wrote:
> A Netrek client, using pygame, for any operating system supported by
> python and pygame, including Microsoft Windows, MAC OS X, and Linux.
>
> netrek-client-pygame 0.5 was released, with huge changes since 0.4,
> including messaging, RCDs, introductory documentation, and flexible
> screen resolution.
>
> http://quozl.us.netrek.org/netrek-client-pygame/ has screenshots.
>
> http://quozl.linux.org.au/netrek-client-pygame/
> b346e3bdec6167811fce2eb62af73119  netrek-client-pygame-0.5.tar.gz
>    

Cute. Is it missing some things like the galactic?

I like the graphics. :-)

Cheers,
mark



From netrek at gmail.com  Wed Mar 24 10:38:25 2010
From: netrek at gmail.com (Zachary Uram)
Date: Wed, 24 Mar 2010 11:38:25 -0400
Subject: [netrek-dev] netrek-client-pygame-0.5 released
In-Reply-To: <4BAA2F91.9080402@mark.mielke.cc>
References: <20100324103111.GA8594@us.netrek.org>
	<4BAA2F91.9080402@mark.mielke.cc>
Message-ID: <ecfa260c1003240838x37af5ef1q4fe6d459ac90f645@mail.gmail.com>

Who made the graphics? Nice!

Zach

<>< http://www.fidei.org ><>


From billbalcerski at gmail.com  Wed Mar 24 12:29:48 2010
From: billbalcerski at gmail.com (Bill Balcerski)
Date: Wed, 24 Mar 2010 13:29:48 -0400
Subject: [netrek-dev] netrek-client-pygame-0.5 released
In-Reply-To: <ecfa260c1003240838x37af5ef1q4fe6d459ac90f645@mail.gmail.com>
References: <20100324103111.GA8594@us.netrek.org>
	<4BAA2F91.9080402@mark.mielke.cc>
	<ecfa260c1003240838x37af5ef1q4fe6d459ac90f645@mail.gmail.com>
Message-ID: <45ab86181003241029s73f1f144w30b912f6dad578d2@mail.gmail.com>

The planet and ship graphics are those originally made by Stas Pirigov (I
also did some minor work on colorizing planet graphics) and have been
included in the Windows XP client since 2006.
Bill

On Wed, Mar 24, 2010 at 11:38 AM, Zachary Uram <netrek at gmail.com> wrote:

> Who made the graphics? Nice!
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20100324/3ea07ca4/attachment.htm 

From billbalcerski at gmail.com  Wed Mar 24 12:31:33 2010
From: billbalcerski at gmail.com (Bill Balcerski)
Date: Wed, 24 Mar 2010 13:31:33 -0400
Subject: [netrek-dev] netrek-client-pygame-0.5 released
In-Reply-To: <45ab86181003241029s73f1f144w30b912f6dad578d2@mail.gmail.com>
References: <20100324103111.GA8594@us.netrek.org>
	<4BAA2F91.9080402@mark.mielke.cc>
	<ecfa260c1003240838x37af5ef1q4fe6d459ac90f645@mail.gmail.com>
	<45ab86181003241029s73f1f144w30b912f6dad578d2@mail.gmail.com>
Message-ID: <45ab86181003241031j16c14e53ne17ded5600be907e@mail.gmail.com>

Sorry I got confused it is Pascal Gagnon not Stas who made the graphics.

On Wed, Mar 24, 2010 at 1:29 PM, Bill Balcerski <billbalcerski at gmail.com>wrote:

> The planet and ship graphics are those originally made by Stas Pirigov (I
> also did some minor work on colorizing planet graphics) and have been
> included in the Windows XP client since 2006.
> Bill
>
>
> On Wed, Mar 24, 2010 at 11:38 AM, Zachary Uram <netrek at gmail.com> wrote:
>
>> Who made the graphics? Nice!
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20100324/0d33bbac/attachment.htm 

From netrek at gmail.com  Wed Mar 24 15:40:09 2010
From: netrek at gmail.com (Zachary Uram)
Date: Wed, 24 Mar 2010 16:40:09 -0400
Subject: [netrek-dev] netrek-client-pygame-0.5 released
In-Reply-To: <45ab86181003241031j16c14e53ne17ded5600be907e@mail.gmail.com>
References: <20100324103111.GA8594@us.netrek.org>
	<4BAA2F91.9080402@mark.mielke.cc> 
	<ecfa260c1003240838x37af5ef1q4fe6d459ac90f645@mail.gmail.com> 
	<45ab86181003241029s73f1f144w30b912f6dad578d2@mail.gmail.com> 
	<45ab86181003241031j16c14e53ne17ded5600be907e@mail.gmail.com>
Message-ID: <ecfa260c1003241340x21bf2425i1fc26a8e7c78b649@mail.gmail.com>

Ah ok. They look a lot better at this larger size than shrunken down
IMHO. Would be nice if we had a professional graphic designer we could
call on when needed.

Zach

<>< http://www.fidei.org ><>



On Wed, Mar 24, 2010 at 1:31 PM, Bill Balcerski <billbalcerski at gmail.com> wrote:
> Sorry I got confused it is Pascal Gagnon not Stas who made the graphics.


From quozl at us.netrek.org  Wed Mar 24 16:46:44 2010
From: quozl at us.netrek.org (James Cameron)
Date: Thu, 25 Mar 2010 08:46:44 +1100
Subject: [netrek-dev] netrek-client-pygame-0.5 released
In-Reply-To: <4BAA2F91.9080402@mark.mielke.cc>
References: <20100324103111.GA8594@us.netrek.org>
	<4BAA2F91.9080402@mark.mielke.cc>
Message-ID: <20100324214644.GM1242@us.netrek.org>

On Wed, Mar 24, 2010 at 11:28:17AM -0400, Mark Mielke wrote:
> Cute. Is it missing some things like the galactic?

No, there's a galactic, just that I neglected to capture a screenshot of
it.  I've updated the web page with a screenshot of the galactic.

http://quozl.us.netrek.org/netrek-client-pygame/

Direct link to the screenshot only:

http://quozl.us.netrek.org/netrek-client-pygame/0.5-galactic.jpg

Anticipating feedback ... no, the team shading is not changed as the
planet ownership changes, and the on screen rendering of the Romulan
planet names is a lot easier to read ... when you don't convert the
screenshot to JPEG.)

-- 
James Cameron
http://quozl.linux.org.au/


From quozl at us.netrek.org  Wed Mar 24 16:48:01 2010
From: quozl at us.netrek.org (James Cameron)
Date: Thu, 25 Mar 2010 08:48:01 +1100
Subject: [netrek-dev] netrek-client-pygame-0.5 released
In-Reply-To: <45ab86181003241031j16c14e53ne17ded5600be907e@mail.gmail.com>
References: <20100324103111.GA8594@us.netrek.org>
	<4BAA2F91.9080402@mark.mielke.cc>
	<ecfa260c1003240838x37af5ef1q4fe6d459ac90f645@mail.gmail.com>
	<45ab86181003241029s73f1f144w30b912f6dad578d2@mail.gmail.com>
	<45ab86181003241031j16c14e53ne17ded5600be907e@mail.gmail.com>
Message-ID: <20100324214801.GN1242@us.netrek.org>

On Wed, Mar 24, 2010 at 01:31:33PM -0400, Bill Balcerski wrote:
> Sorry I got confused it is Pascal Gagnon not Stas who made the graphics.

There's a credit to that effect in the screenshots ... the outfit
screen, where it says "ships by pascal".

-- 
James Cameron
http://quozl.linux.org.au/


From quozl at us.netrek.org  Wed Mar 24 16:50:02 2010
From: quozl at us.netrek.org (James Cameron)
Date: Thu, 25 Mar 2010 08:50:02 +1100
Subject: [netrek-dev] netrek-client-pygame-0.5 released
In-Reply-To: <ecfa260c1003241340x21bf2425i1fc26a8e7c78b649@mail.gmail.com>
References: <20100324103111.GA8594@us.netrek.org>
	<4BAA2F91.9080402@mark.mielke.cc>
	<ecfa260c1003240838x37af5ef1q4fe6d459ac90f645@mail.gmail.com>
	<45ab86181003241029s73f1f144w30b912f6dad578d2@mail.gmail.com>
	<45ab86181003241031j16c14e53ne17ded5600be907e@mail.gmail.com>
	<ecfa260c1003241340x21bf2425i1fc26a8e7c78b649@mail.gmail.com>
Message-ID: <20100324215002.GO1242@us.netrek.org>

On Wed, Mar 24, 2010 at 04:40:09PM -0400, Zachary Uram wrote:
> Ah ok. They look a lot better at this larger size than shrunken down
> IMHO. Would be nice if we had a professional graphic designer we could
> call on when needed.

What has worked better is:

1.  developers making their own graphic assets,

2.  developers having a short list of what is desired, so that when
another Pascal Gagnon appears we can give them the list.

;-)

So if you think further graphic assets are needed, work with the
developers to ensure they are in the relevant bug trackers or feature
request lists.

-- 
James Cameron
http://quozl.linux.org.au/