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@...> Key fingerprint = F785 DDFC CF94 7CE8 AA87 3A9D 3895 26F1 0DDB E378
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 ><>
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
_______________________________________________ netrek-dev mailing list netrek-dev@... http://mailman.us.netrek.org/mailman/listinfo/netrek-dev
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(Continue reading)
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,(Continue reading)
=- 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.
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.(Continue reading)
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.(Continue reading)
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 ><>
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:
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.
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
_______________________________________________ netrek-dev mailing list netrek-dev@... http://mailman.us.netrek.org/mailman/listinfo/netrek-dev
RSS Feed1 | |
|---|---|
17 | |
2 | |
1 | |
8 | |
40 | |
17 | |
1 | |
6 | |
9 | |
13 | |
4 | |
13 | |
1 | |
10 | |
2 | |
6 | |
1 | |
6 | |
16 | |
9 | |
63 | |
32 | |
4 | |
3 | |
13 | |
32 | |
9 | |
79 | |
74 | |
27 | |
51 | |
18 | |
7 | |
7 | |
11 | |
10 | |
130 | |
16 | |
46 | |
24 | |
10 | |
120 | |
46 | |
69 | |
11 | |
2 | |
6 | |
1 | |
78 | |
100 | |
120 | |
49 | |
49 | |
141 | |
142 | |
43 | |
51 | |
107 | |
99 | |
15 | |
15 | |
52 | |
24 | |
186 | |
466 | |
103 | |
12 | |
38 | |
41 | |
6 | |
9 | |
1 | |
1 | |
9 | |
6 | |
3 | |
10 | |
1 | |
2 |
