rec.games.netrek FAQ List
Tom Holub
Last-Updated: 21 Jul 1994
Changes: Minor.
TABLE OF CONTENTS:
1. What is Netrek?
2. It sounds interesting; how do I get started?
3. What's the difference between Xtrek and Netrek?
4. I've seen a game called Nettrek for the Macintosh; is that the same
thing as Netrek?
5. Can I play Netrek on my Mac/IBM PC/Amiga?
6. I would like to start a new server; what kind of hardware will I need?
7. I'm trying to start a new server, and I'm having problems. Where can I
get help?
8. How do I get people to play my server?
9. I compiled the client source, but every time I try to connect to a server
it kicks me out or tells me to get a 'blessed' binary. What gives?
10. The game runs fine, but when the Netrek window comes up, I can't type
anything into it. How can I fix this?
11. OK, the game runs fine and I found a server and logged in, but there
doesn't seem to be anyone else around. How can I find a game with
people in it?
12. OK, now I'm in a game with other people. What do I do?
13. When I'm playing the game, people keep sending messages to me. How can
I talk back to them?
14. I would like to change what some of the keys do; for example, I'd
like 't' instead of 'T' to activate my tractor beam. Is there a way
to change this?
15. How does the rating/promotion system work?
16. I keep dying. How can I get better at the game?
17. What is 't-mode'?
18. What does DI stand for, anyway?
19. Some of the servers and clients are called 'UDP'; what does that mean?
20. Some of the servers and clients are called 'RSA'; what does that mean?
21. I keep reading about the INL; what is it?
22. I have some ideas and/or bug fixes for the INL Server; where should I
send them?
23. I'm looking at stats from a clue/INL game; what do all the abbreviations
mean?
24. Where can I get the most recent copy of this FAQ list?
25. My GPA has fallen 25% since I started playing Netrek last semester.
How do you find time to do your homework and still make Admiral?
NOTE: If you are using rn or trn, you can use ^G to browse through
the answers.
Subject: 1. What is Netrek?
Netrek is a 16-player graphical real-time battle simulation with a
Star Trek theme. The game is divided into two teams of 8 (or less), who
dogfight each other and attempt to conquer each other's planets. There
are several different types of ships, from fast, fragile scouts up to
big, slow battleships; this allows a great deal of variance in play
styles.
Netrek is set up as a client/server combination; if you want to play,
you'll need the client binary for your machine (most are X-based).
Subject: 2. It sounds interesting; how do I get started?
First, you need to get a client binary for your machine; read the
Netrek FTP List (which is usually posted along with this FAQ
list) to find an FTP site. The client should run on anything that
runs X Windows, although the slower your machine is, the harder it's
going to be to play. Slow networks are even harder to play with.
If you don't know how to use FTP, ask your local guru about it.
If you don't have access to FTP, you can use the mail server at
decwrl.dec.com. Mail ftp...@decwrl.dec.com with 'help' in the body
(nothing else) and you'll get an automatic reply with instructions.
Once you have the binary, rename it to something logical like 'netrek'
and run it with 'netrek -h <hostname> -p <port>'. Read the Netrek Server
List to find a server near you; the nearer, the better.
If you get a 'netrek: Permission denied' message, try 'chmod 755 netrek'.
After the game is over, try 'man chmod.'
Subject: 3. What's the difference between Xtrek and Netrek?
Xtrek is a precursor to Netrek. It has many of the same elements,
but it doesn't work as well because it isn't set up as a client-server
combination.
Unfortunately, Netrek is often called Xtrek. This causes much confusion.
This newsgroup really is dedicated to Netrek, but feel free to talk about
Xtrek if you want; many people here play both.
Subject: 4. I've seen a game called Nettrek for the Macintosh; is that the
same thing as Netrek?
No. Nettrek is in the same family as Netrek (it's unclear which was
created first), but it's not the same game. It runs over Appletalk
and doesn't have a whole lot of complexity. If you're interested in it,
the original version can be found in most net archive sites that support
Mac games. The most recent version is a commercial program called
"Nettrek 3.0 - The Real Version," and is published by Premiere Technology,
Inc.
Subject: 5. Can I play Netrek on my Mac/IBM PC/Amiga?
There is a playable client for the Amiga that runs over a Dnet connection
to a Unix host. Read the Netrek FTP List to find out where you can get
it.
There is a newly released client for a Macintosh connected to a Unix host;
it's slow but playable. There is also a client for Macs connected to the
net via MacTCP (including SLIP/PPP) but it's not yet playable.
If you are running Linux or 386BSD on your IBM PC, there are clients that
will work, although at 14.4K baud they are kinda sluggish. Look on
ftp.csua.berkeley.edu for information on how to run a client under Linux.
Subject: 6. I would like to start a new server; what kind of hardware will
I need?
The server should run on anything that has Sys V shared memory and a good
amount of CPU power. Good net connections are essential if you want
lots of players.
Read the Netrek FTP list to find out where you can get the server
source.
Please get the permission of your sysadmins before setting up a server.
Netrek doesn't need any additional bad publicity.
Subject: 7. I'm trying to start a new server, and I'm having problems. Where
can I get help?
Read the Netrek FTP list to find out where the server-secrets files are
stored (currently at gs69.sp.cs.cmu.edu).
There is also a server maintainer's mailing list, net...@iastate.edu.
If you want to be put on the list, mail a short message to
netrek-...@iastate.edu and include the amount of C experience
you have, how much you know about netrek code, and anything else
that might be interesting.
Subject: 8. How do I get people to play my server?
Generally, people call up the Metaserver (see below) and try to get into
a game that already has people in it. If your school has a bunch of
people who play netrek, encourage them to use your server and people
from other places will begin to. If you don't have a local netrek
population, log on to the machine yourself and fight Hosers.
The other option is to modify the server enough that people are
interested in it for the novelty. Several of the more popular servers
have been created this way (Sturgeon and Paradise come to mind). Keep
in mind, if you do this, that you will attract weenies more than
serious players.
Subject: 9. I compiled the client source, but every time I try to connect to
a server it kicks me out or tells me to get a 'blessed' binary.
What gives?
It's possible to modify the client source to do lots of tedious tasks
(like aiming, dodging, that sort of thing) for you. Since this gives
you a big advantage over a mere human, netrek has a way of knowing whether
you have a client that was compiled by the netrek Gods or by you. If
you compiled it, netrek will assume it's a cyborg, and will kick you out
if it's not cyborg hours. Check the Netrek Server List for cyborg
hours of the servers; sometimes they're legal, sometimes they aren't.
There are several different messages you can get when your binary
isn't what the server is expecting:
1: "User binary failed to verify."
The server is expecting a standard blessed client; read the netrek FTP
list to find out where you can get one.
2: "No customized binaries. Please use a blessed one."
You have an RSA client, but the key for your client isn't on the list.
Mail the server god if you think your key should be included.
3: "You need a spiffy new RSA client for this server!"
You have a standard blessed client (or an unblessed client) but the
server accepts only RSA clients; read the netrek FTP list to find out
where you can get one.
If you are interested in playing a cyborg, get the source
from one of the FTP sites and start hacking, or download one of the
public cyborgs. It's probably not a good idea for new players to
use cyborgs; cyborg players get called lots of nasty names, and
they tend not to learn how to play the game (since their client is
doing most of the work). There is a mailing list for borg authors,
mail trekwrite...@b62103.student.cwru.edu to get on it.
Subject: 10. The game runs fine, but when the Netrek window comes up, I can't
type anything into it. How can I fix this?
This is a problem under a few window managers (OpenWindows and ovlwm, for
example); it's netrek's fault, but you can fix it by adding the line
"<window manager name>.FocusLenience: True" to your .Xdefaults file.
Log out and log back in and it should work. Also, sometimes moving the
mouse cursor out of the netrek window and back in will fix it.
Subject: 11. OK, the game runs fine and I found a server and logged in, but
there doesn't seem to be anyone else around. How can I find
a game with people in it?
Andy McFadden has written a nice little utility called Metaserver II
(based on METASERVER, written by ERic Mehlhaff) that will tell you
where there are active games. telnet metaserver.ecst.csuchico.edu 3520
lists all known servers and current number of players. You can also try
telnet metaserver.ecst.csuchico 3521, 3522, 3523, or 3524 for more information.
Subject: 12. OK, now I'm in a game with other people. What do I do?
The first thing you should do is bring up your message window (by
hitting '?') and your player list (by hitting 'L'). Pressing a number
key chooses your warp speed. The left mouse button fires torpedos at
your cursor, the middle mouse button fires phasers at your cursor, and
the right mouse button turns your ship towards your cursor. Hitting
'h' will bring up a help window with a list of basic commands.
Subject: 13. When I'm playing the game, people keep sending messages to me.
How can I talk back to them?
On the bottom right-hand side of your main window you'll see two
long boxes. The top one is where messages like "Not enough fuel for
phaser" come up just before you die. The bottom one is the one you
use to talk to people. Move your cursor down there and type a character
to choose who to send the message to: 'A' for ALL, the capitalized
team letter for the team (i.e., 'F' for Federation), or the player
number for a message to a single player (i.e., 'c' to send to Rc).
Type your message and hit enter when you're done. Don't do this in
combat.
Subject: 14. I would like to change what some of the keys do; for example, I'd
like 't' instead of 'T' to activate my tractor beam. Is there
a way to do this?
There are two ways: first, do a shift-O. This brings up the options
window. Near the bottom there is a box for 'New keymap entries'.
Move your cursor to this box and type your new keymap entries. The
format is <newchar><oldchar>, so 'tT' will remap tractor beam to 't'.
Netrek also recognizes a .xtrekrc file; a 'keymap:' line in there
will allow you to map as many as you want. Format is the same
as above.
If you forget where you mapped a key, remapping it to itself ('ee', for
example) will reset that keymap.
Subject: 15. How does the rating/promotion system work?
Do a shift-I on yourself; you'll see four ratings there, one for planets,
one for bombing, one for offense, and one for defense. The planet,
bombing, and offense ratings are measured in DI/hour; for each planet
you take, army you bomb, and player you kill you get a certain amount
of DI (which varies depending on the server)--the average amount per
hour is your rating. Your rating is equal to (your DI/your hours)/
(total DI/total hours); therefore, if you have a bombing rating of
2.0, you bomb twice as many armies as the average person on the server.
This is true for all ratings. All ratings are updated only in t-mode.
Now do a shift-U. Listed there are the thresholds for each rank.
Your overall rating is your planets+bombing+offense. To make a rank,
you need to have the DI required for that rank, and your ratings need
to be above the rating required for that rank (i.e., to make Admiral,
you need 320 DI and your ratings need to be above 8.0). You can also
make a ranking by having ratings good enough for a level and *twice*
the DI you would need for the next level (So you can make Admiral
with ratings of 7.0 and 640 DI). This equation is recursive, so you
can also make it with 6.0 ratings and 1280 DI (which would take about
200 hours), or 5.0 ratings and 2560 DI (which would take 500). On some
servers the equation is recursive only once, so you can't make ranks on
8xDI.
On some servers, your defense also needs to be above .8 to advance
past Lt. Commander.
Note that suggestions on how to improve the rating system occur
about twice a week in rec.games.netrek, and the general consensus
is that it isn't worth the hassle.
Subject: 16. I keep dying. How can I get better at the game?
The best way is probably to talk with someone who knows how to play.
There is also an archive of hints and suggestions on how to play
better; read the Netrek FTP List to find out where it is
located.
Subject: 17. What is 't-mode'?
T-mode is short for 'tournament mode.' To keep some integrity in the
database, ratings are calculated only when there are a certain number
of people in the game (actually, when there are a certain number of
people on two separate teams. On many servers, you need 4 players
on 2 different teams; 4 teams of 2 players won't do it). When
the game goes into t-mode, there will be a 't' flag in your list
of flags, and there will be a message like "Dan Quayle declares self
as Galactic Emperor and chaos breaks out!" When the game drops out
of t-mode (because someone quit), the 't' flag will disappear and
there'll be a "Dan Quayle is locked up and order returns to the galaxy"
message.
It's generally considered rude to bomb or take planets out of t-mode.
Some servers punish people for trying.
Subject: 18. What does DI stand for, anyway?
Destruction Inflicted.
Subject: 19. Some of the servers and clients are called 'UDP'; what does
that mean?
UDP is a network protocol that is much more lenient than TCP (which is
what netrek originally used). If you don't have a local server, using a
UDP client on a UDP server could reduce your lag considerably.
Read the Netrek FTP List to find out where you can get a UDP client.
(Many thanks to Andy McFadden, Netrek Guru, for implementing the UDP
stuff).
Subject: 20. Some of the servers and clients are called 'RSA'; what does
that mean?
RSA is a new way for servers to make sure that players are not using
cyborg clients. The RSA package generates a header file containing
a public and a private encryption key. These keys are compiled into
the client; the private key encrypts the data and the public key
decrypts it. The main advantage of RSA over the old reserved.c
method is that the server gods need know only the public key; the
RSA package can be kept in a few select hands. Also, if someone
breaks the protection on a certain private key, that key can be
turned off by the server god, and that client will no longer work.
Subject: 21. I keep reading about the INL; what is it?
The INL is the International Netrek League, a collection of teams from
around the world who periodically beat up on each other. Applications
for the spring season are now closed; if you want to join an exsisting
team, mail the captain or post on rec.games.netrek. All INL administrative
stuff is available by anonymous FTP from ftp.csua.berkeley.edu, in the
directory /pub/netrek/INL (this includes directions on how to sign up). Mail
t...@soda.berkeley.edu if you have any questions about the INL.
Subject: 22. I have some ideas and/or bug fixes for the INL server;
where should I send them?
If it's a change to the game or the INL rules, you should mail the
INL Council at inlco...@soda.berkeley.edu. If it's just a bug
fix or a new statistics idea or something, there's a mailing list
for INL Server hackers at i...@cs.montana.edu
Subject: 23. I'm looking at stats from a clue/INL game; what do all the
abbreviations mean?
The INL server records many statistics. A typical example looks like this:
Planets Armies Kills Deaths
----------- ------------------- --- ---Good-----Bad -------
Name team min tpt tpd tpb tab tac pad fao eao tof eck pck tek fck def acc
Mojo Riser F9 85 5 6 8 14 38 73 0 10 112 7 10 93 0 85 9
Name: The player's name.
team: The player's team and player number.
min: Number of minutes the player was in the game.
tpt: Total planets taken.
tpb: Total planets destroyed (neutralized).
tpb: Total planets bombed.
tab: Total armies bombed.
tac: Total armies carried.
pad: Percentage of armies dropped. In this case I carried 38 armies,
dropped 28 of those (on enemy planets or friendly planets needing
reinforcement), and was ogged with 10 (ow).
fao: Friendly armies ogged (blew up on the carrier AGAIN?).
eao: Enemy armies ogged (DOOSH!).
tof: Total offense; a measure of how far away from the homeworld you were,
compared to other team members. Lower is further.
eck: Enemy carriers killed (see eao).
pck: Potential carriers killed (people with kills, but no armies).
tek: Total enemies killed.
fck: Friendly carriers killed (see fao).
def: Deaths by enemy fire.
acc: Actual carriers created; people who got their first kill from me and
picked up armies, or who got their second kill from me and picked up
3 or more armies.
Subject: 24. Where can I get the most recent copy of this FAQ list?
You can either look in the back messages of rec.games.netrek, or
get it via anonymous FTP from ftp.csua.berkeley.edu, directory /pub/netrek.
It's also in the Usenet archive at rtfm.mit.edu.
telnet metaserver.ecst.csuchico.edu 3524 gives the server information
from the server list.
Subject: 25. My GPA has fallen 25% since I started playing Netrek last
semester. How do you find time to do your homework and
still make Admiral?
Sorry, nobody's found an answer to this one yet. Just remember that
(GPA+kill ratio) is constant.
Tom Holub
Archive-Name: games/netrek/server-list
Changes: Various.
This is a list of all known public Netrek servers. If you know of any
others, or if any of my information is wrong, please mail
t...@soda.Berkeley.EDU.
Note: All servers are UDP unless noted otherwise.
Subject: Vanilla servers in America (short listing)
Description: These servers are based on the orignal code, Terence Chang's
bronco code, or Nick Trown's New Vanilla release. They are
not all identical but they have minimal modifications.
Server name INET address Port Notes
bronco.ece.cmu.edu 128.2.210.65 2592 Now RSA only.
calvin.usc.edu 128.125.62.143 2592 USC, RSA.
fife.ecn.purdue.edu 128.46.130.169 2592 Purdue.
netrek.cs.mcgill.ca 132.206.51.3 2592 Canada.
garnet.cdf.toronto.edu 128.100.31.36 5555 Canada.
wormhole.ecst.csuchico.edu 132.241.1.117 5858 Replaces guzzler, RSA.
netrek.unh.edu 132.177.131.238 2592 UNH, RSA only.
bigbang.astro.indiana.edu 129.79.157.41 2592 Indiana, RSA.
rosebud.umiacs.umd.edu 128.8.120.103 2592 Maryland.
mean.mu.caltech.edu 131.215.143.6 2592 Caltech, borgish.
panda.cs.mun.ca 134.153.1.131 2592 Canada.
tolstoy.afit.af.mil 129.92.140.38 2592
Subject: Vanilla servers outside America (short listing)
Description: Same as above but not in America.
peanuts.informatik.uni-tuebingen.de 134.2.14.1 2592 Germany.
bayes.ibr.cs.tu-bs.de 134.169.34.33 5855 Germany.
legend.cma.fr 192.33.149.2 2592 France, RSA only.
netrek.chemietechnik.uni-dortmund.de 129.217.174.20 592 Germany.
ghost.dsi.unimi.it 149.132.1.2 2592 Italy, RSA.
netrek.cs.bham.ac.uk 147.188.192.10 2592 U.K. RSA only.
megalag.risc.uni-linz.ac.at 193.170.38.158 2592 Replaces melmac.
fisher.psy.vu.nl 130.37.96.2 2592 Amsterdam.
rsls6.sprachlit.uni-regensburg.de 132.199.136.36 2592 Germany.
Subject: Sturgeon-style upgrade servers (short listing)
Description: These servers are based on Donald Tsang's Sturgeon source.
They include ship upgrades, a modified combat system,
ridiculous starbases, and more.
rosebud.umiacs.umd.edu 128.8.120.103 7654 U Maryland.
netrek.engg.ksu.edu 129.130.41.86 3333 Kansas State.
Subject: Paradise-style servers (short listing)
Description: These servers use the NetrekII/Paradise source. Paradise
servers can be configured to many settings, including that
simulating a regular bronco server. The source code release
includes an expanded galaxy, impluse/warp differentiation,
suns, extra ships, and more.
netrek.cis.ufl.edu 128.227.224.254 2592 UFL, RSA only.
ravel.theo-physik.uni-kiel.de 134.245.67.30 2592 Germany.
aedile.icaen.uiowa.edu 128.255.17.38 2592 Iowa.
eelpout.micro.umn.edu 128.101.245.6 2592 UMN.
fantasia.eng.clemson.edu 130.127.152.72 2592 Clemson
minuet.skypoint.com 199.86.32.2 2592 ?
fred.cs.city.au.uk 138.40.91.2 2592 UK.
cygnus.cis.ksu.edu 129.130.10.88 2592 Kansas State.
ulcb190.residence.gatech.edu 199.76.99.204 2592 Georgia Tech.
ocisgi6.unizh.ch 130.60.144.76 2592 Switzerland.
Subject: Hockey servers (short listing)
Description: These are servers based on Terence Chang's netrek hockey mode
(as modified by Brick Verser). It's impossible to describe,
you have to try it.
hockey.ksu.edu 129.130.6.10 2592 Kansas State.
rosebud.umiacs.umd.edu 128.8.120.103 6666 U Maryland.
hot.caltech.edu 131.215.9.49 2592 Cal Tech.
Subject: KSU Chaos servers (short listing)
Description: These are servers based on the original KSU Chaos mods. They
include galaxy-class ships, high refuel rates, free plasmas,
wrap-around walls, and much more.
netrek.engg.ksu.edu 129.130.41.86 5855 Kansas State.
Subject: Dogfight servers (short listing)
Description: These are servers designed with dogfighting tournaments in mind.
The code is still rather buggy.
rosebud.umiacs.umd.edu 128.8.120.103 3333 U Maryland.
Comments and server configurations:
NOTE: It is an excellent idea to read the MOTD when you first log
on to a server (use 'f' and 'b' to move forwards and backwards through
the news).
Subject: Vanilla servers in America (long listing)
bronco.ece.cmu.edu:
Server source: Guzzler source.
UDP: version 1.0.
Hours: 5PM-9AM Eastern time Monday-Friday, all day on weekends.
T-mode: 5 on 5.
Maintainer: net...@bronco.ece.cmu.edu
Comments: This server is down most of the time.
calvin.usc.edu
Server source: Scam source.
Hours: Open 24 hours.
Cyborgs: Never allowed, blessed binary required.
Maintainer: had...@ics.uci.edu
Comments: Jacked-up AS's and transwarp.
fife.ecn.purdue.edu
Server source: Bronco source.
Hours: 5PM-8AM EST Monday-Friday, all day on weekends.
Cyborgs: Never allowed, RSA client required.
Maintainer: tma...@ecn.purdue.edu.
Comments: DD's have 8000 fuel. Iggy is active.
This server was down at the time of testing.
netrek.cs.mcgill.ca
Server source: Bronco source.
Hours: Open 24 hours.
Cyborgs: Never allowed.
Maintainer: ke...@cs.mcgill.ca
garnet.cdf.toronto.edu
Server source: Guzzler source.
Hours: Open 24 hours.
wormhole.ecst.csuchico.edu
Server source: Guzzler source.
Hours: Open 24 hours.
Cyborgs: Never allowed, RSA client required.
Maintainer: tr...@ecst.csuchico.edu.
Comments: This server requires RSA. Now has the calvin database.
Supports short packets, ping reporting, and RCD.
Clue checking 5PM-6AM weeknights, all day on weekends.
netrek.unh.edu
Server source: Bronco source
Hours: Open 24 hours.
Cyborgs: Never allowed, RSA client required.
Maintainer: r...@baal.unh.edu.
Comments: Was experimental, is now normal Bronco. RSA clients required.
bigbang.astro.indiana.edu
Server source: Guzzler source.
Hours: Open 24 hours.
Cyborgs: Never allowed, RSA client required.
Maintainer: net...@bigbang.astro.indiana.edu
Comments: Playerlist on port 2591. finger net...@bigbang.astro.indiana.edu
gives a high score list. Ship stats modified to weaken cruisers.
rosebud.umiacs.umd.edu (2592)
Server source: Guzzler source.
Hours: Open 24 hours.
Maintainer: ct...@umiacs.umd.edu
Comments: Has the UML player database. Note port number; port 6666 has
a hockey server.
mean.mu.caltech.edu
Server source: Guzzler source.
Hours: Open 5PM to 8AM weekdays, all day on weekends.
Cyborgs: Encouraged, no binary checking.
Maintainer: kan...@hot.caltech.edu
panda.cs.mun.ca
Server source: Guzzler source.
Hours: Open 24 hours.
Cyborgs: Never allowed, RSA client required.
Maintainer: step...@cs.mun.ca.
tolstoy.afit.af.mil
Server source: Guzzler source.
Hours: Open 24 hours.
Subject: Vanilla servers outside America (long listing)
peanuts.informatik.uni-tuebingen.de
Server source: Bronco source.
Hours: 5PM-7AM Monday-Friday, all day on weekends.
Cyborgs: Allowed.
Maintainer: j...@peanuts.informatik.uni-tuebingen.de.
bayes.ibr.cs.tu-bs.de
Server source: Bronco source.
Hours: Open 24 hours.
Cyborgs: Always allowed.
Maintainer: sch...@ibr.cs.tu-bs.de.
This server was down at the time of testing.
legend.cma.fr
Server source: Guzzler source.
Hours: Open 24 hours.
Cyborgs: Never allowed, RSA client required.
Maintainer: j...@cma.cma.fr.
Comments: Requires message reading.
Supports short packets and RC_DISTRESS.
netrek.chemietechnik.uni-dortmund.de
Server source: Bronco source.
Hours: Closed 8 AM to noon Monday-Friday.
Maintainer: h...@plato.Chemietechnik.Uni-Dortmund.DE.
Comments: No Iggy.
This server was down at the time of testing.
ghost.dsi.unimi.it
Server source: Bronco source.
Hours: Open 5PM-10AM Monday-Friday, all day on weekends.
Cyborgs: Always allowed.
Maintainer: ca...@ghost.dsi.unimi.it.
netrek.cs.bham.ac.uk
Server source: Bronco source.
Hours: 5PM to 8AM Monday-Friday, all day weekends.
T-mode: 4 on 4.
Cyborgs: Never allowed, RSA client required.
Maintainer: A.Wi...@cs.bham.ac.uk.
megalag.risc.uni-linz.ac.at
Server source: Guzzler source.
Hours: Open 24 hours.
T-mode: 3 on 3.
Cyborgs: Never allowed, RSA client required.
Maintainer: si...@risc.uni-linz.ac.at.
Comments: Usually runs in base practice server mode. Suppots short packets
and RC_DISTRESS. Replaces melmac.
orca.cosy.sbg.ac.at: This server is apparently down.
fisher.psy.vu.nl
Server source: Guzzler source.
Hours: Open 24 hours.
T-mode: 4 on 4.
Cyborgs: Never allowed, RSA client required.
Maintainer: r...@psy.vu.nl.
Comments: Clue hours 5PM to 8PM local time.
rsls6.sprachlit.uni-regensburg.de
Server source: Guzzler source.
Hours: Open 24 hours.
Subject: Sturgeon-style upgrade servers (long listing)
rosebud.umiacs.umd.edu (7654)
Server source: Sturgeon source.
Cyborgs: Never allowed, RSA client required.
Maintainer: ct...@umiacs.umd.edu.
Comments: Note port number, netrek on 2592, dogfight on 3333, hockey on 6666.
netrek.engg.ksu.edu (3333)
Server source: Sturgeon source.
Cyborgs: Allowed.
Maintainer: grey...@engg.ksu.edu.
Comments: Note port number, chaos server on 2592.
Subject: Paradise-style servers (long listing)
pippin.ee.usu.edu: This server is apparently down.
netrek.cis.ufl.edu
Server source: Paradise source.
Hours: Open 24 hours.
Maintainer: th...@aviator.cis.ufl.edu
Comments: This is Arctica, another branch of the Paradise line.
ravel.theo-physik.uni-kiel.de
Server source: Paradise source.
Hours: Open 24 hours.
Maintainer: molg...@theo-physik.uni-kiel.de
Comments: Good round-trip times.
aedile.icaen.uiowa.edu
Server source: Paradise source.
Hours: Open 24 hours.
eelpout.micro.umn.edu
Server source: Paradise source.
Hours: Open 24 hours.
Comments: This is Eden, another branch of the Paradise line.
fantasia.eng.clemson.edu
Server source: Paradise source.
Hours: Open 24 hours.
Maintainer: tta...@harley.cs.unc.edu.
This server was down at the time of testing.
minuet.skypoint.com
Server source: Paradise source.
Hours: Open 24 hours.
fred.cs.city.ac.uk
Server source: Paradise source.
Hours: Open 24 hours.
Maintainer: deo...@city.ac.uk.
cygnus.cis.ksu.edu
Server source: Paradise source.
Hours: Open 24 hours.
Maintainer: tun...@cis.ksu.edu.
Comments: This is Armageddon, a mixture of Paradise and KSU Chaos.
ulcb190.residence.gatech.edu
Server source: Paradise source.
Hours: Open 24 hours.
ocisgi6.unizh.ch
Server source: Paradise source.
Hours: Open 24 hours.
Subject: Hockey servers (long listing)
hockey.ksu.edu
Server source: Guzzler source, hockey mode.
Hours: Open 24 hours.
Cyborgs: Allowed.
Maintainer: b...@hobbes.ksu.ksu.edu.
Comments: Hockey mode all the time, send 'help' to player j for details.
rosebud.umiacs.umd.edu (6666)
Server source: Guzzler source, hockey mode.
Hours: Open 24 hours.
Cyborgs: Never allowed, RSA client required.
Maintainer: ct...@umiacs.umd.edu.
Comments: Note port number, normal netrek server runing on port 2592.
hot.caltech.edu
Server source: Guzzler source, hockey mode.
Hours: Open 5PM-8AM weekdays, all day weekends.
Maintainer: kan...@hot.caltech.edu
Subject: KSU Chaos servers (long listing)
netrek.engg.ksu.edu (2592)
Server source: KSU Chaos.
Hours: Open 24 hours.
Cyborgs: Allowed.
Maintainer: grey...@engg.ksu.edu.
Comments: KSU Chaos with grit-style robots.
Subject: Dogfight servers (long listing)
rosebud.umiacs.umd.edu (3333)
Server source: Guzzler source, dogfight mode.
Hours: Open 24 hours.
Cyborgs: Not allowed, RSA client required.
Maintainer: ct...@umiacs.umd.edu.
Comments: Note port number; normal netrek on port 2592, hockey on port 6666.
Tom Holub
Archive-Name: games/netrek/ftp-list
Changes: charon.amdahl.com and pittslug.sug.org now no longer supporting
netrek archives; if you know suitable mirrors please let me know.
Contents:
FAQ LISTS
BLESSED CLIENTS
UNBLESSED CLIENTS (borgs)
SERVER SOURCE
UTILITIES
TIPS/ADVICE
INL STUFF
LIST OF SITES
HYPER-LINKS
If you are using rn/trn (or possibly others), you can use ^G to browse
from subject to subject.
Subject: FAQ LISTS
Summary: The latest versions of the rec.games.netrek FAQ, server, and FTP
lists.
Location: ftp.csua.berkeley.edu /pub/netrek
rtfm.mit.edu /pub/usenet/rec.games.netrek
Subject: BLESSED CLIENTS
Summary: The compiled binaries listed under this category are 'blessed,'
which means that most servers will accept them at all times
(unblessed clients get booted out). There are two types of
blessing, reserved.c (old) and RSA (new). Most servers are
now accepting only RSA-blessed clients. With some RSA clients,
you need to use -R on the command line to enable RSA blessing.
-o enables old-style blessing.
Name: COW (Client Of Win)
Author: Team, distributed by si...@risc.uni-linz.ac.at.
Description: The next step in BRM development; feature-packed but relatively
stable. Supports sound.
Source: ftp.risc.uni-linz.ac.at /pub/netrek/cow
infant2.sphs.indiana.edu /pub/netrek/COW
Compiled binaries:
Dec Ultrix ftp.risc.uni-linz.ac.at /pub/netrek/cow
infant2.sphs.indiana.edu /pub/netrek/COW/COW-bin
Dec Alpha infant2.sphs.indiana.edu /pub/netrek/COW/COW-bin
SGI ftp.risc.uni-linz.ac.at /pub/netrek/cow
infant2.sphs.indiana.edu /pub/netrek/COW/COW-bin
Sun 3 ftp.risc.uni-linz.ac.at /pub/netrek/cow
infant2.sphs.indiana.edu /pub/netrek/COW/COW-bin
Sun 4 ftp.risc.uni-linz.ac.at /pub/netrek/cow
infant2.sphs.indiana.edu /pub/netrek/COW/COW-bin
Solaris 2.3 infant2.sphs.indiana.edu /pub/netrek/COW/COW-bin
Linux ftp.risc.uni-linz.ac.at /pub/netrek/cow
infant2.sphs.indiana.edu /pub/netrek/COW/COW-bin
HP 700 ftp.risc.uni-linz.ac.at /pub/netrek/cow
infant2.sphs.indiana.edu /pub/netrek/COW/COW-bin
AIX 3.2 infant2.sphs.indiana.edu /pub/netrek/COW/COW-bin
Sequent PTX infant2.sphs.indiana.edu /pub/netrek/COW/COW-bin
Name: BerkeleyRicksMoo 3.00+
Author: Team, distributed by l...@mtek.chalmers.se.
Description: Outdated by COW (above), but still a popular client.
Note: ftp.cs.chalmers.se is currently down.
Source: ftp.chemietechnik.uni-dortmund.de /netrek/src
Compiled binaries:
Dec Ultrix ftp.chemietechnik.uni-dortmund.de /netrek/bin
Sequent PTX ftp.chemietechnik.uni-dortmund.de /netrek/bin
ftp.risc.uni-linz.ac.at /pub/netrek/bin.rsa
SGI ftp.chemietechnik.uni-dortmund.de /netrek/bin
crissy.berkeley.edu /pub
Sun 4 ftp.chemietechnik.uni-dortmund.de /netrek/bin
Sun 3 ftp.chemietechnik.uni-dortmund.de /netrek/bin
Linux ftp.csua.berkeley.edu /pub/netrek/linux
crissy.berkeley.edu /pub
FreeBSD ftp.chemietechnik.uni-dortmund.de /netrek/bin
Solaris ftp.chemietechnik.uni-dortmund.de /netrek/bin
Name: COW-lite 1.20+
Author: Team, distributed by she...@iastate.edu.
Description: A smaller version of COW; a full-featured client, but
engineered for speed. Supports RSA, short packets, ping stats,
and RCD.
Source: soils.agron.iastate.edu /pub/netrek/COW-lite
Compiled binaries (more to come):
SGI soils.agron.iastate.edu /pub/netrek/COW-lite
Sun 4 soils.agron.iastate.edu /pub/netrek/COW-lite
RS6000 soils.agron.iastate.edu /pub/netrek/COW-lite
Name: Berkeley client
Author: mehl...@ocf.berkeley.edu.
Description: Also a full-featured client, including some stuff not in BRM.
Supports RSA and short packets. Netrek For Morons mode (-M).
This client is NOT INL-legal.
Source: ocf.berkeley.edu /pub/netrek/Sources
Compiled binaries:
Dec Ultrix ocf.berkeley.edu /pub/netrek/Binaries
HP Apollo ocf.berkeley.edu /pub/netrek/Binaries
Sequent/DYNIX ocf.berkeley.edu /pub/netrek/Binaries
Sun 3 ocf.berkeley.edu /pub/netrek/Binaries
Sun 4 ocf.berkeley.edu /pub/netrek/Binaries
Name: BRM-Hadley 1.7+
Author: had...@ics.uci.edu
Description: A version of Berkricksmoo streamlined for speed. Good
client for slow machines. Supports RSA, short packets, and
ping stats. There is also a FONTBASED version for the sun 3
which uses fonts instead of bitmaps for the ships; this should
speed things up considerably.
Source: cad.ics.uci.edu /pub/netrek
Compiled binaries:
Sun 3 cad.ics.uci.edu /pub/netrek
Sun 4 cad.ics.uci.edu /pub/netrek
Linux ftp.csua.berkeley.edu /pub/netrek/linux
cad.ics.uci.edu /pub/netrek
HP 700 cad.ics.uci.edu /pub/netrek
SGI cad.ics.uci.edu /pub/netrek
MIPS cad.ics.uci.edu /pub/netrek
Name: RomaBerkMoo
Author: she...@iastate.edu
Description: A client based on BRMH, but with many features from the latest
BRM added. Supports RSA, short packets, and RC_DISTRESS.
Source: Unavailable.
Compiled binaries:
Dec soils.agron.iastate.edu /pub/netrek
Name: Bronco client
Author: ?
Description: A bare-bones client. Supports RSA.
Source: Currently homeless as far as I know.
Name: Paradise client 2.0+
Author: Team, paradise...@reed.edu.
Description: A client for the new Paradise server. Fully compatible with
non-Paradise servers, but the RSA key isn't accepted on all
servers. Supports RSA. More visually appealing than most
clients. This client is needed to play on Paradise servers.
Source: ftp.cis.ufl.edu /pub/netrek.paradise
Compiled binaries:
Sun 3 ftp.cis.ufl.edu /pub/netrek.paradise
Sun 4 ftp.cis.ufl.edu /pub/netrek.paradise
Sun Solaris ftp.cis.ufl.edu /pub/netrek.paradise
SGI ftp.cis.ufl.edu /pub/netrek.paradise
RS6000 ftp.cis.ufl.edu /pub/netrek.paradise
HP Apollo ftp.cis.ufl.edu /pub/netrek.paradise
HP9000 s700 ftp.cis.ufl.edu /pub/netrek.paradise
Decstation ftp.cis.ufl.edu /pub/netrek.paradise
Linux ftp.cis.ufl.edu /pub/netrek.paradise
Name: VMS client
Author: ?
Description: Client for VMS. Features unknown. Reportedly does not support
RSA.
Source: ftp.uml.edu /netrek/VMS
Compiled binaries:
VMS ftp.uml.edu /netrek/VMS
Name: Vax Ultrix client
Author: ?
Description: Client for Vax Ultrix. Supports RSA? Features unknown.
Source: Unavailable.
Compiled binaries:
Vax Ultrix ftp.unh.edu /pub/submissions/netrek/local
Name: MacNetrek version 1.0/Netrek Display Bridge
Author: jia...@postgres.berkeley.edu
Description: This client allows you to play on a Macintosh connected to a
unix host via a 9600+ baud modem. You need both the Netrek
Display Bridge (ndb, on the unix end) and the Mac client
itself.
Source: ftp.csua.berkeley.edu /pub/netrek/MacNetrek/src
Compiled binaries:
Sun 4 ftp.csua.berkeley.edu /pub/netrek/MacNetrek
Dec 3100 ftp.csua.berkeley.edu /pub/netrek/MacNetrek
HP 700 ftp.csua.berkeley.edu /pub/netrek/MacNetrek
Name: Winetrek (MS-Windows/ndb client)
Author: cm...@netcom.com
Description: This client allows you to play on an IBM PC connected to a
unix host via a 9600+ baud modem. You need both the Netrek
Display Bridge (ndb, on the unix end) and the Winetrek client
itself. NOTE: This uses an older version of ndb than MacNetrek
does; they are not compatible (yet).
Source: ftp.netcom.com /pub/cmlee/winetrek/ndb/src
Compiled binaries:
Sun 4 ftp.netcom.com /pub/cmlee/winetrek/ndb/bin
Name: MacTCP client
Author: n...@cs.nott.ac.uk
Description: This is an alpha-testing version of a client that runs on
a Macintosh connected to the net via MacTCP. It now works
in a basically playable manner. Does NOT support RSA yet.
Source: Not available.
Compiled binaries:
Macintosh nyquist.cs.nott.ac.uk /pub/mac_client
Name: Amiga client
Author: je...@cbmvax.cbm.com
Description: This client allows you to play on an Amiga connected to a unix
host via a 9600+ baud modem if you have the beta version of
release 2 of the Commodore Amiga AS225 TCP/IP package, or
AmiTCP with the clone of socket.library.
There is also a compiled server binary here.
Source: Currently homeless.
Name: Amiga DNetrek client
Author: mehl...@ocf.berkeley.edu
Description: This client allows you to play on an Amiga connected to a
unix host using the DNet windowing program. It is very new
and experimental (alpha release).
Source: ocf.berkeley.edu /pub/amiga
Compiled binaries:
Amiga ocf.berkeley.edu /pub/amiga
Name: Amiga DNetrek Paradise client
Author: jru...@csld.ucr.edu
Description: A later version of the above, including Paradise mods. It
requires 2 megs of RAM, OS 2.0 or higher, a fast modem, a
Unix host, and DNet (see above). Supports RSA, short packets,
and synthesized speech for messages.
Source: Available upon request.
Compiled binaries:
Amiga ftp.cis.ufl.edu /pub/netrek.paradise
Subject: UNBLESSED CLIENTS (Borgs)
Summary: The clients listed here are not blessed and will be booted out of
servers which do binary checking. These clients have various
features which aid standard human play (such as auto-aiming,
auto-firing, auto-dodging, etc.)
Name: Sunborg
Author: Roger Wong (Scout Popcorn)
Description: Your basic simple borg client.
Source: Unavailable.
Compiled binaries:
Sun 4 grind.isca.uiowa.edu /unix/netrek/binaries
Name: Grandfather borg
Author: David Teo
Description: Borg client with full robot mode.
Source: Unavailable.
Compiled binaries:
Sun 4 grind.isca.uiowa.edu /unix/netrek/binaries
NeXT grind.isca.uiowa.edu /unix/netrek/binaries
Decstation grind.isca.uiowa.edu /unix/netrek/binaries
Subject: SERVER SOURCE
Summary: This is a listing of all known netrek server sources. Before you
try to set up a server, make sure your sysadmin approves. Also,
running a server takes rudimentary programming skills and the
ability to understand and use 'make' and other Unix tools; don't
expect to be able to FTP one of these packages and have a server
up and running with no effort.
Name: Scam server
Author: Kevin Smith and Scott Silvey
Description: The original source. Now quite outdated and hard to compile.
Location: scam.berkeley.edu /src/games/xtrek
Name: New Vanilla Server 2.2+
Author: Nick Trown
Description: The latest release of the vanilla netrek server. The most
up-to-date and portable, highly recommended.
Source: ftp.ecst.csuchico.edu /pub/netrek/src
Compiled binaries:
Linux ftp.csua.berkeley.edu /pub/netrek/linux
ftp.risc.uni-linz.ac.at /pub/netrek/bin.misc
Name: Bronco server
Author: Terence Chang
Description: The most widely used source package. Also somewhat outdated
but generally a solid release.
Location: gs69.sp.cs.cmu.edu /code
ftp.cis.ksu.edu /pub/Games/netrek
Name: INL Server
Author: Ray Jones, Eric Mehlhaff, and now i...@cs.montana.edu.
Description: This server is required for INL games, and is the best for
organized, fixed-length games. Latest revision is 4.00pl8.
Location: crissy.berkeley.edu /pub
Name: KSU Chaos Server
Author: ?
Description: Chaos mode with galaxy-class ships. Used to be quite popular,
isn't so much anymore.
Location: ftp.cis.ksu.edu /pub/Games/netrek
Name: Paradise Server
Author: Team, paradise...@reed.edu.
Description: Larger galaxy, many new ship types, lots of new rules. A much
different game than standard netrek. Still under development.
Location: ftp.cis.ufl.edu /pub/netrek.paradise
Name: Base practice server (binary only)
Author: Tedd Hadley
Description: A server specifically for practicing basing, as seen at
vlsi.ics.uci.edu. Includes base ogg robots. Binary only.
Compiled binaries:
Linux: ftp.risc.uni-linz.ac.at /pub/netrek/bin.misc/linux-nt.tgz
Subject: UTILITIES
Summary: This is a collection of netrek-oriented utilities, some for server
gods and some for netrek players. There are probably more out there
which I've failed to list.
Name: xsg
Author: Tedd Hadley (had...@cad.ics.uci.edu) (originally Andy McFadden)
Description: An X version of the 'showgalaxy' server tool. Allows the server
god to change ship stats, planet stats, watch the game, and much
more.
Location: cad.ics.uci.edu /pub/netrek
pittslug.sug.org /pub/netrek
Name: trekhopd
Author: Andy McFadden (fad...@netcom.com)
Description: This allows people who are behind an Internet firewall to play
netrek. trekhopd runs on the firewall, and your client calls
up trekhopd. Installation instructions are included.
Location: Currently homeless.
Name: pledit
Author: Andy McFadden (fad...@netcom.com)
Description: This allows server gods to edit their player database.
Location: Currently homeless.
Name: ckplayers
Author: ?
Description: Tool to call up a server and get a list of people playing. If
there is a wait queue, it reports its length.
Location: gs69.sp.cs.cmu.edu /code
Name: XnetrekM
Author: Tedd Hadley (had...@cad.ics.uci.edu)
Description: Motif-based front end to the Metaserver.
Location: cad.ics.uci.edu /pub/netrek
gs69.sp.cs.cmu.edu /code
Name: RES-RSA package.
Author: Team.
Description: This is the key generation/encryption/decryption package for
server gods and client builders. It can be legally obtained
only by US and Canadian citizens; mail tr...@ecst.csuchico.edu
for the key to decrypt the source package.
Location: ftp.ecst.csuchico.edu /pub/netrek/src
Name: PGP (RSA clone) package.
Author: James Hawtin
Description: This is a PGP-based implementation of the RSA key generation/
encryption/decryption package for server gods and client
builders. It can be legally used anywhere outside the USA.
In the USA, using it is a patent violation.
Location: ftp.risc.uni-linz.ac.at /pub/netrek/src
Subject: TIPS/ADVICE
Summary: These are collections of advice for new players as well as
old-timers.
Location: gs69.sp.cs.cmu.edu (default directory)
Comments: This a collection of advice culled from the old CMU netrek
bboard, and then from alt.games.xtrek and now rec.games.netrek.
There is all kinds of good stuff here about how to play various
ships and roles. There is also a sample .xtrekrc. You'll find
definitions of words like 'ogg' here. There are also tips on how
to get a server running, and much more. This archive is available
over AFS (cd /afs/cs.cmu.edu/user/jch/netrek) and WAIS
(gourd.srv.cs.cmu.edu, port 6000, name netrek-ftp).
Subject: INL STUFF
Summary: This is where you can find stuff related to the International
Netrek League.
Name: Administrative documents
Location: ftp.csua.berkeley.edu /pub/netrek/INL
Comments: The latest versions of all documents related to the INL can be
found here, including current rosters, schedules, etc.
Name: INL Server
Author: Ray Jones, Eric Mehlhaff, and now i...@cs.montana.edu.
Description: This server is required for INL games, and is the best for
organized, fixed-length games. Latest revision is 4.00pl8.
Location: crissy.berkeley.edu /pub
Subject: LIST OF SITES
Summary: A short listing of all known FTP sites.
scam.Berkeley.EDU 128.32.138.1 The original site (now outdated).
ftp.csua.berkeley.edu 128.32.149.19 INL administrata, FAQ lists.
crissy.berkeley.edu 128.32.156.224 INL server.
ftp.cd.chalmers.se 129.16.79.20 Berkeleyricksmoo client.
ocf.berkeley.edu 128.32.184.252 Berkeley client.
ftp.cis.ksu.edu 129.130.10.80 Mirrors.
gs69.sp.cs.cmu.edu 128.2.206.167 Learn to play here!
b62103.student.cwru.edu 129.22.242.151 NeXT stuff.
ftp.iastate.edu 129.186.140.11 Little bit of everything.
iacrs2.unibe.ch 130.92.11.4 Source for IBM rs6k/AIX.
sgi.com 192.48.153.1 Silicon Graphics binary.
cad.ics.uci.edu 128.195.1.42 UDP client.
ftp.coe.montana.edu 192.31.215.240 Mirrors.
ftp.informatik.uni-rostock.de 139.30.5.23 Galaxy client.
ftp.ulowell.edu 129.63.32.1 VMS client.
ftp.unh.edu 132.177.128.99 VAX Ultrix client.
duke.me.chalmers.se 129.16.50.80 ntpatch source.
ftp.chemietechnik.uni-dortmund.de 129.217.174.20 Mirrors gs69.sp.cs.cmu.edu.
tbird.cc.iastate.edu 129.186.140.11 Game recorder server mod.
ftp.risc.uni-linz.ac.at 193.170.33.112 RSA stuff/ENL archive.
nyquist.cs.nott.ac.uk 128.243.22.10 Sparc sound client.
ftp.cis.ufl.edu 128.227.100.252 Paradise clients.
legend.cma.fr 192.33.149.2 Various clients and docs.
ftp.reed.edu 134.10.2.24 Mirror of ftp.cis.ufl.edu.
Subject: HYPER-LINKS
Summary: FTP For Morons(TM)
<p><hr><ul><a href="http://obsidian.math.arizona.edu:8080/netrek.html"><img
src="http://obsidian.math.arizona.edu:8080/login.gif" alt="Netrek"></ul></a>
<a href="ftp://infant2.sphs.indiana.edu/pub/netrek/COW/COW-bin/">FTP Link</a>
<A HREF="http://jasper.bbn.com:8001/Netrek">
http://www2.ecst.csuchico.edu/~trown/netrek/wormhole
http://www-engr.uvic.ca/~jbaker/Oggsquad/oggsquad.netrek.html
Tom Holub
Last-Updated: 20 Jul 1994
Note: This was written by Andy McFadden but is now being maintained by me
along with the other FAQ lists. Many thanks to Andy for compiling it
(in addition to his other contributions to the netrek world).
The same ideas get proposed over and over by people trying to enhance the
game, and the same discussions come up again and again. This file is an
attempt to stem the flow by presenting old discussions and arguments
against the ideas.
This assumes you are familiar with the game itself and some of the
vocabulary (argot) involved (e.g. scum, ogg, LPS, Iggy). This is NOT
intended to be a capsule summary of rec.games.netrek discussions; it is
intended to help people trying to enhance the game understand why many of
the obvious improvements won't work or won't be accepted by the Netrek
community. As such, it contains one-sided and occasionally opinionated
material. I welcome improvements and stronger arguments, but if you want
to debate the value of something I will probably ignore you.
[ This file has been evolving since September of 1992. Some of the info
may have become outdated as Netrek evolved. ]
REMEMBER: Netrek is not Star Trek. Netrek is not reality. Star Trek is
not reality. Netrek is not Nintendo. DO NOT suggest modifications purely
to make the game "more realistic". ONLY consider ideas that will improve
game play.
CONTENTS:
1) How about team DI?
2) How about no DI at all (+ changes in general)?
3) All ships shouldn't fire 8 torps.
4) Let's make cloakers blind.
5) Let's allow cloakers to fire.
6) The DD needs to be improved.
7) Here's a neat idea for a new ship.
8) How about a ship design system?
9) Remove the kill restriction on army carrying.
10) Remove the kill restriction on plasma torps.
11) Get rid of LPSs.
12) Get rid of Iggy!
13) Combine all of the server processes into one.
14) Put the number of armies next to the planet.
15) Highlight ships with kills.
16) Prevent bombing/taking out of T-mode.
17) Stop 3rd race scumming.
18) Just have a two-race galaxy.
19) Add incentives for scout bombing.
20) Protect ships that are fully lagged.
21) Credit kills appropriately.
22) Get rid of borgs!
23) Change the names of the races or the planets.
24) Add ship collisions.
25) Give planets gravity or motion.
26) Show the list of players or a "rank weighting" on entry.
27) Set up an invitation-only clue server.
28) Allow ships to drop mines.
29) Have the client update the torps instead of the server.
30) Have ships come in at the starbase instead of a planet.
31) Ships should auto-repair at warp 0.
32) Change the way the wait queue works.
33) Add steering keys.
34) Prevent butt-torping.
A1) Appendix: Sturgeon II changes
A2) Appendix: Sturgeon II kill credit rules
A3) Appendix: Extreme Netrek
A4) Appendix: How to propose a change
You can skip straight to the one you're interested in (say, chapter 2) by
searching for the regular expression "^2)".
1) How about team DI?
Problem:
Too many rank scums out there for themselves. Need to add an incentive for
team play, so that they will get more DI if their team does better.
Proposal:
Change the DI structure so that you get points for stuff your teammates do.
Alternatively, change it so that you get points for different "team stuff",
like taking strategically placed planets or killing carriers.
Why not:
Most "team DI" schemes will cause people to switch to the team that's
winning, because that's where the points are. It is possible right now to
see the players on each team before making the initial team selection; this
would make unfair teams the rule.
Changing the individual values of things is difficult when you consider how
the current DI scheme works. "DI" is simply the sum of offense, bombing,
and planet ranks, multiplied by the number of hours you have been playing,
and then adjusted according to the global average. There are no fixed DI
values for doing certain things; just your relationship to the rest of the
people on the server.
If you try to reward players on teams that are doing well, people will
quit when their team starts to lose, creating a steamroll effect (all
the clued people join the winning side, all the non-clues stay on the
losing side). Keeping track of planets won/lost during a game is a nice
idea, but will lead to a lot of quit-scumming when the other team is
taking a planet or two. Rank scums will always be scums; you can change
the rules but they will always find annoying ways of working around them.
Killing people with armies gives you (5*armies) bombing credit, and taking
core planets is worth more than other planets, so the incentives exist;
people are simply unaware of them or feel it is easier to do things the
scum way.
Incidentally, DI works like this:
- There are three factors: bombing (the number of armies you have,
bombed), offense (the number of enemies you have killed), and
planets (the number of planets you have taken). There's also defense
(number of times you have been killed), but most servers have done
away with the defense criteria since ogging became popular.
- The server takes these values, considers how long it took you to
get them, and then compares that against the server average. From
this you get "ratings", where having a 1.0 bombing rating means you
bomb as many armies per unit time as the average player, 2.0 ratings
mean you bomb twice as many, and so on.
- The bombing, planet, and offense ratings are added. This gives your
total ratings. An average player would have 3.0 ratings.
- The ratings are multiplied by the number of hours you have spent in
t-mode on that server. This is your DI.
Hitting 'U' (shift-u) while playing brings up a chart showing what ratings
and how many hours you need to make a particular rank. You can also promote
if you don't have the ratings but have twice the DI, or if you're ratings
are two points down and you have four times the DI. You can't be demoted.
Many players are under the misconception that you "get DI" for doing a
particular action. You don't.
2) How about no DI at all?
Problem:
DI is a mistake. It is the reason for scumming.
Proposal:
Toss it. At least toss all the ranks above Captain.
Why not:
Many people like to advance in rank. DI was developed because the original
Xtrek had nothing but win/loss stats, so ratio scumming was the only way to
look impressive (you think DI is bad... heh). There are a large number of
Admirals who like having their rank (hey, it took them a long time to get
there), and some of them run servers. DI is like the USA's electoral voting
system: it's not great, and the country might be better without it, but it's
not going away without a major fight.
Besides which, it's a good way to attract [scum] players to new servers.
Any change to DI is simply going to shift scumming one way or the other.
Most arcade games are centered around the accumulation of points; the object
is to do certain things, for which you rewarded. The idea of Netrek, however,
is to win the game; rank should be just an incidental feature. However,
there will always be those who see the accumulation of points, rank, or
whatever as the driving goal.
The Holy Grail of DI changing is a system that rewards only non-scum
activities. However, telling scumming from teamwork requires human
intervention or artificial intelligence in most cases.
Jean-Marc Tanzi writes:
>I believe that any team game, like netrek, where a machine could
>really compute how well you play cannot be that good.
Other interesting ideas:
- Have players promote each other. Once you get to a certain rank, you can
promote those beneath you. This has a chicken & egg problem which can be
solved by importing a database or with some active administration at first.
Note this is open to abuses (demoting people you don't like, promoting
really lame players to embarass them, etc), and tends to trivialize rank.
Tried on b62150.student.cwru.edu.
- Shift planet credit so that you get partial credit for making it neutral
and partial credit for taking it. This is accomplished by (for example)
multiplying everybody's planet rating by 3 and then awarding 1 for neuting
and 2 for taking. Since the global average is also multiplied by 3,
player ratings don't change, so DI is constant. Tried on
bigbang.astro.indiana.edu.
3) All ships shouldn't fire 8 torps.
Problem:
The game is unbalanced. SBs should be able to shoot more torps than others.
Maybe SCs shouldn't be able to shoot as many.
Proposal:
Increase SB torps to 12, or scale all others accordingly.
Why not:
Going to 12 torps requires mods to both client and server. This will increase
CPU time slightly, and will increase network usage. You can't just switch
on the ship type, either, because a SB could fire 12 torps and then refit.
Scaling all ships down (so that an SC would fire, say, three torps total)
has been tried on Sturgeon; see appendix A1.
Any change to the ship characteristics is going to be met with a great deal
of resistance. The game is very carefully balanced, and any changes can
result in drastic changes in the way it's played.
4) Let's make cloakers blind.
Problem:
Cloaking is too powerful. Ogging is getting out of hand.
Proposal:
Remove certain items from the tac display of a cloaked ship, like enemy
ships, planets, torps, etc.
Why not:
Been done. Not very popular. Removing planets makes them hard to take
(you just sit there watching your 'O' flag, hoping that nobody will kill
you because they KNOW you are coming straight in). Removing torps is bad
for the same reason.
Removing other players to make ogging harder is bad because most players
LIKE ogging. It's fun, and it's part of the game.
5) Let's allow cloakers to fire.
Problem:
Now that Star Trek VI is out, cloakers (esp. Kli) should be able to fire.
Proposal:
Allow ships to fire when cloaked, possibly with a higher fuel or wtemp cost.
Why not:
Gimme a break. Ogging would become trivial without changes to other parts
of the game. See the Sturgeon changes in Appendix A1.
6) The DD needs to be improved.
Problem:
The DD is weak. It can't take bomb as well as an SC, and it can't fight as
well as CA.
Proposal:
Give the DD bigger shields, or bigger torps (30 is too small), or more
powerful phasers, and perhaps a bigger fuel tank.
Why not:
As Tom Holub put it (paraphrased), "The CA is weak. It can't bomb as well
as a DD, and it can't fight as well as a BB." All ships have their place,
it's just a question of finding the right niche. DDs can carry 5 armies,
making them more of a threat to planets than the SC.
Several discussions have raged over rec.games.netrek about what the One True
Use of the DD is. None have been found. They can't be used as a big SC
nor as a small CA; they require a different perspective. I won't offer
them here, but will instead relegate it to the thrice-revised DD Players Guide.
As a side note, the cooling rate on DDs was changed from 6 to 7, allowing
them to go great distances without overheating. Many players who previously
thought the DD fully worthless now consider it to be valuable in certain
circumstances. For those of you who are beginning to think that I'm totally
anti-change, let it be known that I sent private e-mail to about ten different
server deities asking them to make this change, and campaigned long and hard
on rec.games.netrek.
I detest the phrase, "Ship of Lose." It doesn't even make sense. Stop it.
Newer, alternative proposals:
- make the CA weaker, by reducing phaser strength or manuverability (but
then the SC gets correspondingly stronger)
- have a reentry delay based on ship size (again, the SC gets stronger)
- give the DD mondo plasmas, making it a special-purpose ship
- remove the DD entirely so people stop whining
7) Here's a neat idea for a new ship.
Problem:
There's a gap in Netrek that really needs to be filled.
Proposal:
I want a new ship X that can do Y and Z.
Why not:
KSU-Galaxy/Chaos servers are a prime example of ship design run amok. The
GA had huge torps, fast phasers, an incredible refueling rate, and eventually
they even boosted the manuverability on some servers. As a result, nobody
played anything but GA (there were some DD holdouts, but once you could turn
in GA at a reasonable warp most of those switched over).
You may think your new design will fit perfectly into Netrek. You're
probably wrong. Some examples from the past:
- mini-starbase. Like your normal SB, but less filling. You'd get a couple
on a team, or maybe just have them more often. Two of these together,
pressoring each other out of danger, would be damn near invincible when
guarding a repair planet. It's basically a Super Planet Defender, like
a BB on steroids, and it really wouldn't add anything new to the game,
since it's easier to ogg than an SB and slower than a BB.
- fighters. SBs would launch these, perhaps they'd be robot-controlled.
Again, neat idea, but so what? They would either have to occupy a player
slot (reducing the number of other robots you can have) or require
modifications to both client and server (which is a Bad Thing). Again,
what do they add? Are they any different from plasma torps with a high
tracking setting? See the Sturgeon changes, which implemented them as
slow-moving tracking torps, which SBs could fire instead of normal torps.
- floating fuel platform. Another pseudo-SB, which looks like an AS but
has fuel like an SB. Easy ogg target; what good is it if you have to keep
it sitting behind your home planet? One BB can off the thing, so it's
not even valuable as a distraction.
- ogger ship. Maybe it uncloaks fast (a la the old Calvin scheme), or it
does 200 points of damage when it explodes, or it has small torps but a
big phaser, or whatever. Anybody who thinks they need this has never been
ogged by somebody in a CA who knows what they're doing. This would just
make Ogging by Idiots that much easier.
- super scout ship. Strip off most offensive weaponry, make it real fast.
What's the point? Try stopping a good SC player, and THEN see if you
really want to propose this.
- big fat starbase. This one has the actual size increased, making it easier
to hit, but is given better shields to compensate. So what's the point...?
It would involve changing a lot of code in the server and client to special
case the various options, plus new bitmaps (for shield/cloak as well),
etc, etc.
Many suggestions like these come from people trying to compensate for
inadequacies in the ships (sounds vaguely Freudian, doesn't it?) It takes
time and a lot of practice to become a really effective player; even
the lowly SC can be a marvelous dogfighting ship when it's flown by a
skilled player (with no lag).
The "paradise" server introduced a number of new ships, but it also changed
a LOT of other game features, and required a new client to play. One was
the "jump ship", which could carry 4 players and go warp 30, but had only
25 shields and 25 damage. (Paradise continues to be refined, so I'm not
going to try and describe their setup.)
8) How about a ship design system?
Problem:
Other games (e.g. xtank) allow you to change the way your ship is set up. I
want to be able to adjust my ship characteristics according to the way I play.
Proposal:
Allow ship characteristics to be adjusted by the player.
Why not:
This was implemented in a version of the original Xtrek game. The tendency
was to do things like strip all torpedos, most of the hull, half of the
engines, and all of the cloaking ability from the ship and get phasers that
could do 40 points of damage to ships outside of visual range (but had to
be orbiting a fuel planet to fire more than twice).
Games quickly became ridiculous. Either your planets were being taken by
someone completely invisible, or you were getting destroyed by ships you
couldn't see. Nobody bothered dodging, because nobody fired torps.
Any implementation will require carefully balanced limits and a lot of play
time before it would become widespread. Anyone who wishes to try this will
likely have to set up their own server and then try very hard to attract
players to it.
As a side note, Sturgeon has a feature somewhat like this: predefined ship
upgrades after you get kills. Unfortunately this can (and does) encourage
ratio scumming and runner scumming, because nobody with a nice big fat ship
wants to die. (It also introduced "upgrade scumming" to the world:
repeatedly killing a second login to get lots of upgrades.)
9) Remove the kill restriction on army carrying.
Problem:
Imposing a restriction based on kills is unrealistic and silly.
Proposal:
Allow any player to carry armies.
Why not:
If you allow this, you remove a big part of the challenge of the game.
Getting a kill and staying alive while trying to move armies around is
one of primary challenges in Netrek. If anybody can carry armies, then
every player is a potential planet taker, and it's impossible to focus
the defense of your space.
You will also increase the instances of Ensign Fubar scampering about,
picking up armies and dying with them. This is a Very Bad Thing when your
team is low on armies. If a player can't get a kill, he probably doesn't
have the skill or experience to take a planet without getting nailed.
(People who need practice taking planets need to practice staying alive first!)
For those who insist on reality, it can be argued that Star Fleet Command
doesn't like to entrust armies with commanders who haven't proven themselves
in battle (especially Kli!) It has also been suggested that the captains
use the hull fragments of the enemy starships to build crew accommodations
for the armies.
10) Remove the kill restriction on plasma torps.
Problem:
Requiring kills for plasmas is silly.
Proposal:
Allow plasmas for one and all.
Why Not:
While this is a trivial server change (quick alteration to .sysdef), it's
there for a reason, namely that having 8 battleships with plasma torps makes
taking planets impossible. LPSs would never end. Chaos servers allowed
infinite plasmas, and plasma-wars became rather common. So did plasma-
muggings (you can't shoot three incoming plasmas!) The ping-pong plasmas
made life interesting, but then there's not much point in taking planets
on a Chaos server anyway.
The way things are now, players with 2+ kills can be ogged, which prevents
them from firing more plasmas.
While it's true that the rich become richer (or perhaps the deadly become
more deadly), there's nothing wrong with elitism in Netrek. It's just a
game. Deal with it.
11) Get rid of LPSs.
Problem:
LPSs suck. They're boring and they make my stats hurt.
Proposal:
Various ideas. A small sampling:
- have a 5 second delay before players can reenter
- have a delay inversely proportional to the number of planets your team has
- enter moving away at maxwarp
- have the presence of enemy ships force new ships to appear farther away
(a la Plato Empire)
- enter without fuel (this is also used as an anti-psycho-ogging "fix")
- use the random entry planet selection stuff, extended to work on planets
that the team doesn't own
- allow a certain number of construction points per minute; big ships use
more construction points; once exceeded, you have to wait for it to climb
back up
- genocide happens when only one planet remains
- allow a ship with 5 or 10 kills to carry a MondoBomb; when it reaches the
planet it obliterates it
- turn an SC with 3 kills into Super Ogger, doing several hundred points of
damage with its explosion
Why Not:
The Last Planet Stand is one of the few things in Netrek that absolutely
REQUIRES teamwork. It is nearly impossible to break an LPS unless the
attackers are organized or the defenders are largely clueless.
A reasonable solution to the Indefinite LPS (one that drags on and on
because all the clued players on the attacking side bailed) is the Bronco
LPS timer. The attackers get 45 minutes to break it, at which point the
galaxy resets. There are players who dislike the timer because it encourages
the attackers to slack off ("oh, we'll just wait for the timer, we'll never
break through), but it's proven to be a reasonable compromise.
LPSs are here to stay. It is possible to come back from one, just as it is
possible to genocide a race. If you are concerned about the damage to your
stats, then set up your own server, scum your way to admiral, and get on
with your life.
There are some ideas floating around about encouraging teams to go for the
genocide, such as resetting the galaxy afterward instead of leaving a
20 planet vs 10 planet setup (whether that's a punishment or a reward
depends on your point of view).
Side note: LPSs with homeworld agris are monumentally unpopular. You can
hold off against a fleet with greater numbers without too much difficulty.
Many servers explicitly prevent the home world from being agri; if your
favorite server doesn't, tell the server admin. (The other side of the
coin is that, once taken, it's harder for the home team to retake. I don't
think this balances the pain of taking it in the first place, however.)
12) Get rid of Iggy!
Problem:
Iggy is nothing but a pain.
Proposal:
Lose him.
Why Not:
Iggy is a Bronco server feature that adds a bit more randomness to the game.
Opinions on Iggy are rather divided, but most everybody seems to have one
(at this point I will plead neutrality so as not to start ANOTHER flame war).
If you really dislike Iggy, either:
- kill him as soon as he shows up,
- ask the server god to remove him, or
- play on servers that don't have him.
Some people will argue that Iggy is "terrain", i.e. a part of the game like
planets (only a bit more aggressive). A common phrase is, "if you're fighting
Iggy, you don't understand him."
Some servers have banned Iggy during t-mode; you might request this. It
should be left to the individual admins however. Some servers (e.g. Calvin)
have snakes instead, which don't really do much but get in your way (they
look cool though).
13) Combine all of the server processes into one.
Problem:
My workstation can't handle all the context switches.
Proposal:
Merge all the ntserv processes into one, and maybe even combine them with
daemonII, so instead of the Server Union we'd have the Unified Process.
Why Not:
A few people have tried this. There are advantages and disadvantages to
doing this, not the least of which is that it requires a complete rewrite of
the server, a partial to full rewrite of the client, and will work best as a
strictly UDP implementation (which requires a whole new protocol).
Among the disadvantages are the possible loss of the shared memory segment
(which kills the traditional tool interface), the need to bring the server
down whenever changes are made, the inability to simply restart failed
components (ex: restartable daemon), changes in CPU load possibly resulting
in lower UNIX process priorities (and thus worse real-time performance),
changes in the way the kernel sees Netrek (e.g. waiting for I/O), poorer
performance on MP machines, the larger executable will be more likely to be
swapped out under BSD, loss of memory firewalls between components,
possibility of security breaches in a UDP-only setup, etc, etc.
There are a number of advantages, but this file is meant to discourage you,
not entice you. A reading of the process scheduling chapter in _The Design
and Implementation of 4.3BSD UNIX_ should be required for anyone contemplating
this.
And if you don't believe me, here's a note from somebody who's doing it now:
-----
Article 11256 of rec.games.netrek:
From: jric...@cs.cs (John 'MacGyver' Richardson)
Date: 30 Dec 92 05:31:11 GMT
[...]
Ok, not to beat a dead dog, but I've been working on this for a while now.
It was pretty easy to come up with multiplexed I/O for logging in. HOWEVER,
the big problems are:
o scheduling becomes a disaster! However, I'm trying reading
one packet from whoever's ready and going on to the next slot.
Updates taken care of by the daemon now get taken care of by
a signal handler.
o reading and writing becomes a disaster! If you use TCP you have
to deal with partial reads and writes of packets because you have
to use nonblocking I/O. If you want to write code, you have to
have states for everything in the universe (so to speak). The
solution? Use UDP only. But that requires a TCP like protocol
to get those packets that absolutely have to get there (like a
login name). Feel like re-inventing the wheel? I sure feel
like I am now. :)
[...]
-----
14) Put the number of armies next to the planet.
Problem:
It's annoying to have to hit 'i' all the time to get army counts.
Proposal:
Put the number of armies on each planet next to the planet's bitmap on the
galactic map.
Why Not:
This is the first step down the path to "Netrek for Morons(tm)". You can see
when a planet pops by watching the galactic map; having ever-increasing army
counts staring you in the face is like having a compass attached to your
nose.
It's true that the information is accessible, if somewhat inconvenient.
However, players who aren't paying attention won't see the new army
numbers, and are less likely to react to an army bitmap on the display than
they are to seeing "15" next to Sir. If you aren't paying attention to
armies, you lose. There are several places in Netrek where this is the
case.
Netrek rewards vigilance and a keen eye as well as intelligence and fast
reflexes. Being constantly aware of everything around you is a challenge
beyond the goals of the game itself; it requires the player to improve
himself, and rewards experience. Doing all but say, "do this next" will
make things too simple, and reduce the sense of accomplishment acquired
from mastery of the game. Knowing exactly where the armies are and how many
requires as much skill as holding a phaser lock, which is as it should be.
There are those who think otherwise. I'm not presenting their opinions here,
because if you are about to propose this then you share those opinions
already. Suffice it to say that there is enough disagreement to keep this
from becoming a standard feature of Netrek.
15) Highlight ships with kills.
Problem:
It's too annoying to have to look down at the player list, and relate that
to the people flying around.
Proposal:
Mark players with kills somehow.
Why Not:
This is yet another stepping stone on the path to ButtHeadTrek. This would
essentially stick a big "Ogg Me" sign on the engines of anybody with a kill.
You don't even have to pay attention to the game to know what you should do
when you encounter a ship with kills.
While this is in the same vein as the army counts, it isn't really
controversial, possibly because the guys who like the army counts also like
to take planets and don't want to get swamped by "stupid oggers."
16) Prevent bombing/taking out of T-mode.
Problem:
Many players either don't know Netrek-etiquette about not messing with
planets outside of T-mode, or they choose to ignore it.
Proposal:
Make the server enforce it.
Why Not:
Actually, I kind of like this one. Sickdog had a mod where trying to bomb
or drop armies out of t-mode caused you to explode.
The main problem with it is that sometimes its okay to bomb out of t-mode.
If you've got a 2-on-2 "training" session and just want to practice trading
planets, it's annoying to have it blocked. Making this policy work without
getting in the way generally requires human intervention. You could do
something fancy, counting how much time has elapsed since t-mode was lost
and take into consideration #of players on a team, etc, etc, but you'd have
to lean on a server deity to get this to happen.
Another problem is that simple "nuke" implementations don't give you enough
warning (one minute you're dropping, the next BOOM!).
Some recent servers simply prevent it by treating the planet as friendly.
This can be a bit confusing, because the message they display (usually the
bronco "no Pearl Harbor" message) doesn't really tell you what's going on.
Any such implementation should also prevent beaming down on planets of a
different race, INCLUDING independents.
17) Stop 3rd race scumming.
Problem:
When players are unable to break an LPS, or they just want more armies, they
may go over to a race with no players and take some planets. This happens
often when a 20-on-10 game has slowed to an impenetrable impasse, and the
team with 20 planets decides to reset the galaxy by capturing a 3rd race.
It's also used to draw LPS defenders away from the planet, and make them
try to defend 3rd race space.
Proposal:
Don't allow 3rd race planets to be taken over.
Why Not:
I really hate 3rd-space scumming, but I'll bite my tongue (ouch!) and try
to give some reasons not to propose this.
First of all, it's already been discussed several times, so unless you plan
to undertake a direct-mail campaign to server deities, forget it. It's been
a part of Netrek for quite some time, and there are some dedicated 3rd-space
scummers out there. It's also a viable (if cowardly) alternative to the
genocide timer, especially on servers that don't have the timer.
However, as one slightly opinionated player put it:
>From: t...@soda.berkeley.edu (Tom Holub)
>Subject: Re: 3rd space planet taking
>Date: 11 Aug 92 07:49:12 GMT
>
>People are for it because they are fuckin' WEENIES who don't want to
>play the game.
> -Mojo
If you propose it, you will have support, but you won't get anywhere unless
you're willing to put your back into it.
Some ideas from the past (other than "just don't allow it"):
- Make war status permanent.
- Force players to be peaceful against all races except their t-mode
opponent.
- Make more intelligent/stronger guardians (go after people with kills, etc).
Unfortunately, a team which is about to perish will likely bomb the 3rd
race to bring in a super-guardian to help defend their new territory
after the genocide (this can be fixed, of course).
- Have robot appear when hostile player ENTERS 3rd space, not just when he
attacks it (presume guilt).
- Make undefended planets do more damage to attackers.
- The neutral race gets ticked, and some planets join the non-offending team
for protection (interesting, but it's actually worse).
- Add robots which actually attack the attacker's space (bombing/taking).
The large number of armies on 3rd race planets makes this attractive.
- Leave it legal for servers without a timer, but simply ban it from servers
with an LPS timer.
- Have a two-race galaxy (see next item).
18) Just have a two-race galaxy.
Problem:
Netrek is a descendant of Empire, which had four warring races. However,
Netrek games typically have only two races fighting each other, so the rest
of the planets are just worthless junk. This increases network/CPU overhead,
and leads to 3rd-race scumming.
Proposal:
Remove two of the races. Leave Fed/Rom, or Rom/Kli (with a reorg of KLI
space).
Why Not:
The other planets serve a variety of uses. They can be used by scout bombers
and planet takers for refueling and repair, and allow cloaking near hostile
space. It also allows 3rd-space scumming, but that's a different issue.
Most importantly, the size of the galaxy increases the area which needs
to be defended. If you reduce the galaxy to a two-way, it will be impossible
to attack from or retreat to neutral space. All offensive actions will take
place in a single corridor, making starbases and large ships much more
important. Bombing and deep planet taking will become more difficult
because there is a single path of attack.
Whether you think this is a good idea or not, there's no denying that it
will dramatically change game strategies. It is unlikely that such a
proposal will be popular.
19) Add incentives for scout bombing.
Problem:
Very few people are willing to SC-bomb because of the drain on stats (too
much time away from taking planets). Bombing 2 or 3 armies at a time doesn't
really help the bombing stats much; ogging carriers may do more.
Proposal:
Change the amount of bombing credit based on the number of armies sitting
on the planet when bombing began. So you'd get massive credit for bombing
the last three armies, but not nearly as much for bombing it from 60 to 55.
Alternate proposal:
Start all planets out at 5 or 6 armies.
Why Not:
Both proposals suffer from the fact that average bombing stats have already
been computed on most servers based on the "one army, one vote" scheme
with 30 initial armies on each planet. Changing the setup mid-stream would
make it nearly impossible to get a 1.0 bombing rating.
It's also highly unlikely that anybody really concerned about rank is going
to do much scout bombing anyway. Advancing bombing at the expense of
offense and planets is not a good way to scum up to Admiral.
The alternate proposal also affects the ability of a starbase to fill up
with 25 armies at the start of a game. Overall, the second proposal will
likely have a dramatic impact on the way the first few minutes of a game
are played - something that isn't likely to go over too well with the "old
timers."
20) Protect ships that are fully lagged.
Problem:
When a client becomes seriously lagged, the player usually ends up getting
snuffed by the first bozo who comes within visual range.
Proposal:
Make a server mod so that ghostbusted players are invulnerable until the
connection gets reestablished.
Why Not:
>From: jc...@cs.cmu.edu (Jonathan Hardwick)
>Subject: Re: Playing with lag
>Date: 11 Aug 92 01:24:29 GMT
>
>Last time it came up, one objection I remember is that it would become
>trivial to abuse. Want to take that last planet? Lock on, cloak, max
>warp, and then yank the ethernet connector out of your machine. Wait
>30 seconds while the defenders waste all their fuel on you, and then
>finally realize that you're in Protected Mode. Stick the ethernet
>connector back in, beam down your armies, genocide the galaxy.
>
>Or if you're worth less when in Protected Mode, just yank the ethernet
>connector whenever death seems inevitable.
Depending on the implementation, you might be able to just hit ^Z and
suspend your process. When the client host's buffers fill up it'll look
just like a network storm to the server host. If all you want to handle
is fully severed clients then you won't be solving the problem; the only
time my client has been severed is when the server goes down (I can't do
the "automatic reconnect" because I'm running through a firewall machine,
so I *know* when I get completely dropped).
21) Credit kills appropriately.
Problem:
The person who causes deaths doesn't always get the credit (e.g. F1 fires
torps at R2; R2 dets; F0 dies from the detted torps. Credit should go to
R2 who did the detting, but currently goes to F1 who fired the torps.)
Proposal:
Implement some fixes to make it work out right.
Why Not:
This is actually a pretty good idea. It won't affect the game much, and
it makes things fair. However...
It will change the game. There were be situations where people who would
have had kills will not got them, and vice versa. Exact impact on the game
needs to be better understood.
A similar idea is to have "kills" and "wins" be the same, for statistical
purposes. So killing a ship with 5 armies would get you 1.5 wins as well
as 1.5 kills. I don't know that this really does anything useful though.
Sturgeon II has some new rules implemented; see appendix A2.
If you would like to take it upon yourself to define a clear-cut set of rules
AND modify a server, test it, AND THEN provide diffs for the rest of the
world, you will probably see this change happen. However, it's probably
more than your average server deity wants to deal with.
22) Get rid of borgs!
Problem:
Cyborgs are evil! They're for loser weenies!
Proposal:
Fully ban them.
Why Not:
Well, this isn't really a "clever suggestion", but it appears so frequently
that I figured I ought to mumble a few words of pseudo-wisdom.
Borgs are neat. You can sit back and watch them destroy everything around
you without moving a finger. This is far more satisfying if the borg you
are using is one that you have written yourself; you're testing your
programming skills and algorithmic cleverness against others. The ultimate
is to write a fully automated android, like SFOP.
Some servers have "borg hours" so that people who want to use them can,
and so that the authors can test them in battle. If you don't like playing
against borgs, find out which servers support them and when, and don't play
during those times.
Generally speaking, people who use cyborgs are atrophying their own skills.
Playing a borg and playing a regular client are two very different things;
after a while you become accustomed to firing without aiming, and to having
oggers snuffed by your auto-pressor and auto-phaser. Going back to being
stricly human can be a difficult experience. For this reason, most
experienced players don't use them.
They do make for an interesting change of pace, and it can be fun to sign
on to a clueless server and munch newbies without breaking a sweat.
"Borgtrek" is also amusing from time to time (100% borg games).
Cyborgs only become a problem when people sneak blessed borgs into human-only
hours. Usually they'll turn most of the offensive weaponry off, but they
usually leave on special features like the ability to determine which players
are carrying armies or special highlights on players with kills. This gives
them an advantage, as they can fight, fly, and be fully aware of what the
other team is doing all at the same time (in some cases they can get
information unavailable to the standard client).
If you really dislike borgs, go play somewhere else, consoling yourself with
the fact that, if they try to play a standard client, they will fare far
worse for their cyborg experience.
23) Change the names of the races or the planets.
Problem:
Feds never fight Klingons, and who are these Orions, anyway? The names
are outdated and don't reflect Trek stuff.
Solution:
Use Ferengi, Cardassians, or some other "real life" hostile races. Change
the names of some of the planets to reflect Star Trek stuff, i.e. use
names like "Farpoint" and "Vulcan".
Why Not:
The names of the races and the planets are ingrained into Netrek players.
If somebody says "clear org", experienced players know where to go without
even looking at the map.
Races are the same way. Everyone who has played for a while is used to Rom
being top left, Orion being lower right, etc. People don't write, "K3 is
scumming in lower-left space". It's Fed space, and it always should be.
Sure, people would get used to it after a while, but I don't think most
people WANT to get used to it. In a few situations it can be a real pain,
such as when the first letter changes. If you want to send a message to the
other team, you have to use a different key. It's also used in a lot of
places in the code, so it'd be a pain to change (and if you didn't change
the code, but rather just the external appearance, it'd be very confusing
for people prying into the source code).
Remember what this document says up top: Netrek is not Star Trek, Netrek is
not Real Life. It's a game, with names chosen as convenient points of
reference. If you want to set up a server with California city names or
campus buildings instead of star systems, feel free.
24) Add ship collisions.
Problem:
It would be neat to have ships collide.
Proposal:
Have ships either damage each other on collision or bounce off in some
elastic manner.
Why Not:
Bouncing ships would be, well, weird. Crunching ships in a BB by rolling
over them would be amusing, but probably wouldn't add much to the game.
However, there are more serious considerations. First, consider what happens
if you are cloaked ogging somebody, and collisions do damage. Now you don't
even need to uncloak to kill the other guy; just run into him. Makes
avoiding oggs nearly impossible, especially since you can't pressor the
attacker away.
Second, suppose you are cloaked taking a planet. As it is the defenders have
to locate you and hit you with enough torps/phaser hits to blow you up.
Escorts can det torps to keep their takers safe. Collisions make it far
easier to defend planets: whether the collisions bounce or do damage, planet
defenders can simply cloak and fly over the planet and have a good chance of
destroying you or at least knocking you off. They don't even have to uncloak
anymore, making it harder for the escorts to do something useful. And if
collisions bounce, you can just knock the escorts into the planet takers.
Heck, if you want to defend a planet, just sit right in the middle, and
nobody else can orbit.
This last issue is a strong reason for disallowing collisions between
friendly players: you could never have more than about four people in orbit
at once, and getting more than two in orbit would require a minor feat of
coordination.
25) Give planets gravity or motion.
Problem:
Planets are boring.
Proposal:
Give planets a gravitational attraction. Also, make them move around, perhaps
in some sort of localized circular pattern.
Why Not:
Gravity is really sort of silly. It won't do anything but make it harder
to get away from a planet. Might be useful for dodging sideways or running,
but you either need to make it too weak to be interesting or too strong
to be playable.
Moving planets is harder than it seems. The client wasn't designed to allow
planets to move. You will also increase the amount of network traffic (by
quite a bit, since planet positions are currently only sent right after you
log on) and the CPU load, which are Bad Things. It really isn't all that
exciting anyway. It can change the galaxy around making Kli or Ori space
more "fair", but any serious amount of movement will have to be carefully
tested so you don't end up with cluster-galaxies and huge neutral zones.
26) Show the list of players or a "rank weighting" on entry.
Problem:
Teams are often unbalanced, because people must blindly choose which team
to join.
Proposal:
Display the list of players, or at least some sort of rank distribution,
to players entering the game. That way they can choose teams to even them
out.
Tom Holub
Last-Updated: 20 Jul 1994
Note: This was written by Andy McFadden but is now being maintained by me
along with the other FAQ lists. Many thanks to Andy for compiling it
(in addition to his other contributions to the netrek world).
Why Not:
People don't choose the less-clued team as a rule. Should they? Yes. Do
they? No. Why? Well, they may be rank scums who want some easy targets
(undefended planets, easy kills, etc), or they may just be sick and tired
of playing on clueless teams. It gets frustrating after a while when you
get killed with 6 armies behind your home planet by four oggers while your
teammates do nothing but shoot torps at you because they think you're a
bad guy (yes, this has happened to me).
It's also difficult to force people onto one team or another; considering
that rank is generally not a good indication of skill, solving the problem
of "what team should I assign this person to" is about as hard as making
DI meaningful.
Incidentally, it IS possible to see a player list before you enter the game.
27) Set up an invitation-only clue server.
Problem:
There are so many clueless weenies flying around that I'm not having fun
anymore.
Proposal:
Set up a clue-only server. Access would be by invitation only, with players
selected by the admin or invited automatically after achieving a certain rank
on certain servers.
Why Not:
It's been tried. auk.warp.cs.cmu.edu was run this way, and nobody ever
played there.
There are two fundamental problems with the proposal. First, the invitation
mechanism is bad. Either the server admin has to spend a fair amount of time
adding players and passwords, or it has to be done automatically. However, as
discussed earlier, rank is a horrible indication of clue, talent, and skill.
Automated systems will be prone to adding clueless players with lots of hours
or missing clueful players who just don't care about rank (or reset their
stats).
Even if that were solved, there's another problem: it's not easy to get 16
clueful players in one place at one time. Players come in and out constantly.
I personally play whenever I (a) have the time and (b) feel like it; I'm
not likely to turn up at a specified hour on a specified server on a
specified day (if I could fit that into my week, I'd be on an INL team).
Getting it organized is a pain and is just too inconvenient for the players
to make it worth doing.
auk failed miserably because nobody worked to get the players there (apparently
it was also a bit on the slow side). If you propose this, be prepared to
accept the burden of organizing it. Many people have said, "somebody should
do this", but nothing will happen until "somebody" steps up and does it.
If you want to set one up, feel free, but don't expect much UNLESS you are
willing to spend a LOT of time massaging the player database, sending e-mail
to players, and doing general organizational stuff.
One acceptable alternative is the "minimal clue" system that Nick Trown came
up with. Basically, after you sign in the server tells you to send a message
to yourself. If you don't, you get blown up, and eventually get kicked out.
All this does is require the player to have the message window *mapped*,
which is a big step toward playing in a clued manner. It has been tried and
generally accepted as a Good Thing, though many feel it doesn't go far enough.
The common scheme these days is to announce "clue games" on rec.games.netrek
with date, time, host name and port number. Since it's not a standard
server the clueless generally don't show up.
28) Allow ships to drop mines.
Problem:
There just aren't enough ways to kill things.
Proposal:
Allow ships to drop mines which explode when you run into them.
Why Not:
The first thing to ask yourself is, what good are they? A new way to
runner scum? Maybe it's supposed to garrison an SB or planet? Or is it
just a new toy add for the hell of it?
They aren't really all that useful unless you want to give them serious
damage capability (say 150 points - otherwise I'll come by in an AS and soak
up half a dozen), in which case they'll be used either while running away at
maxwarp or during oggs, essentially giving you a single big torp. If you
make them more expensive than torps, they won't get used here, but when will
they be used?
Guarding an SB? Just steer around them, or send a suicide minesweeper in.
For a planet? Maybe. It might slow down SC-taking. If they can be destroyed
with phaser shots though then they're pretty much worthless. On the other
hand, during an LPS you could have everyone on your team drop a mine on the
home planet, making it impossible to take.
One proposal was to allow SBs to either fire torps or mines (i.e. you would
choose on an individual basis whether what you fire is going to be a torp or
a mine). This restricts the #of mines active by essentially crippling the
starbase every time it drops one. It also requires that the team HAVE an SB
for them to work at all. Something like this was tried on Calvin.
At any rate, all mine proposals have one major flaw: how to display them.
Unless you want to force a change to the client code, you have to represent
them with a player's torps, plasmas, etc. Unfortunately these tend to look
just like vestigal torps which were "forgotten" by a UDP connection, so
remote players tend to slam into them (or end up swerving around bogus torps).
If you want to get fancy (say, have two standard torps orbiting each other)
you will be using two torps per mine (which might not be a bad thing).
If you're going to propose this, you need to consider:
- who gets them (ship type, #of kills, rank)
- how many each person/team gets
- how they are drawn (plasma, photon, phaser, Iggy?)
- how they are removed (only on collision, at request of "owner", when
phasered, when plasmaed, after n seconds)
- how much damage they do (point-blank damage + blast radius)
- whether or not they can be tractored/pressored/beamed
- whether they can be dropped while cloaked (VERY bad idea)
- who causes them to explode (other team, everyone, all != owner, non-cloakers,
just cloakers, other exploding mines)
- who takes damage (other team, everyone, all != owner)
The really hard part is making them useful but not abuseable.
29) Have the client update the torps instead of the server.
Problem:
A lot of network traffic is spent sending torp updates.
Proposal:
This could be avoided by just sending the "start" packet with direction and
speed, and sending an "end" packet when the torpedo dies.
Why Not:
The main difficulty is losing synchronization with the server. If a "torp
death" packet is lost or delayed, the position of the torpedo will be
inaccurate because of torp wobble or possible early expiration. It might
reduce net traffic, but it could be really confusing.
The biggest obstacle is "torp wobble", which is a random change in direction
added every update. If the client misses an update, the torp will continue
off in the previous direction until the next update arrives, at which point
it will jerk back on course. This can be worked around by sending a random
number seed to the client, and then having the client emulate the wobble,
but this is just making more work for the client and creating the opportunity
for borgs to accurately predict wobbling torps.
30) Have ships come in at the starbase instead of a planet.
Problem:
LPSs are hard to break, and transwarp is nice but not really necessary.
Proposal:
Have ships come in at their starbase instead of a planet.
Why Not:
One big reason is that a traitor SB could drag its entire team off into 3rd
space, allowing an easy genocide by the other team. This isn't a problem
in clued games, but it only takes one bozo.
It has some tactical problems, like making it impossible for the starbase
to sneak around cloaked. Killing the starbase becomes easier or more
difficult depending on where the new ships come in: newbies appearing right
on top of the SB and exploding repeatedly will make it die faster, while
clued players appearing a short distance away will increase its lifespan
by providing a continual escort.
But, worst of all, it makes Ged happy.
You can avoid some of the problems by looking at SB docking permission
or having people set a preference somehow, but the usual question needs to
be answered: does this really enhance the game?
Incidentally, a little-known fact is that ships do NOT have to come in at
the home planet. The server admin can specify a list of planets in the
server .sysdef file, and have one chosen at random. This feature is rarely
used though.
31) Ships should auto-repair at warp 0.
Problem:
It's really inconvenient to have to hit 'R' to repair. It should happen
automatically. Also, it's tough to exit repair to fire weapons.
Proposal:
Have damaged ships auto-repair when they hit warp 0. Also, have repair mode
deactivate when the player fires weapons.
Why Not:
The first part is really silly. If you can't hit 'R' then you need help,
pure and simple. Most of the time I use 'R' when I want to go warp 0 anyway,
because it's easier to hit (if you're used to hitting '0', just map 'R' to
'0'... halfway home). This would only be an advantage when orbiting, and a
minor one at best.
The second part can be implemented as a borgish feature (have repair blink
off when firing) or by simply turning off repair until the user manually
turns it on again. The first would change the game in a big way, because
ships orbiting a fuel/repair planet could be firing and repairing
constantly. The second allows you to come out of repair and start firing
faster, which also represents a change to the game.
Both of these are really "Netrek for Morons(tm)" changes. The game *should*
be a challenge to the player. Learning when to hit 'R' as you're coming in
to orbit (yes, you can hit it before you stop moving) and how to turn repair
mode off before firing are trivial but important skills, and should remain
part of the game.
BTW, this is best implemented in the server, not the client, especially since
"repair" packets can be dropped.
32) Change the way the wait queue works.
Problem:
Sitting on the wait queue sucks.
Proposal:
Either have players with more DI move through the queue faster, or have
the players get booted to the end after every time they die.
Why Not:
For the first one, you're increasing the importance of DI, which will lead
to more scumming. It will also encourage people to play on only one or two
servers, share high-DI logins with friends, and will effectively block
newbies from playing. Increasing the importance of DI is *not* a worthwhile
goal.
In the second case, you're making life incredibly valuable. Nobody will want
to ogg if it means waiting for a couple of minutes to get back in... and
when people start guarding their lives carefully, the wait queue will take
longer and longer to shrink. There is also the (non-trivial) problem of
balancing the wait queue across teams (if three FEDs die do you let three
ROMs in the game, making it 11 on 5?).
33) Add steering keys.
Problem:
Netrek's clumsy and outdated user interface requires you to use the mouse
to steer your ship.
Proposal:
Define keys that turn your ship regardless of the position of the mouse.
These could be incremental (turn 1/16th per keypress) or continuous (keep
turning left until you hit the other one).
Why Not:
There are two very important actions that require you to position the
mouse: dodging and shooting. You can't dodge torps and shoot in the same
instant unless you want to dodge directly at your target. Only borgs
and robots can do this.
A player who practices with these keys for a while will be able to
maintain a continuous phaser lock and fire torps while effectively dodging
enemy torps. There are a few people who can approximate this with the
current setup, but they are among the best dogfighters in the game. This
change would make it much easier for people to reach the pinnacle of
dogfighting skill, which is not a desirable quality in a game. If there's
no challenge, there's no point in playing.
The argument about Netrek's interface being clumsy is ridiculous. F-16
fighter pilots (who fly a very capable combat borg) have stated that they
would've loved to fly in World War I, when combat had more to do with
individual skill and cunning than electronics.
34) Prevent butt-torping.
Problem:
Twinks in DDs keep toasing my CA by firing torps while running away.
Proposal:
Prevent players from butt-torping by altering the way torps fired out
of the rear 60 degrees or so are handled.
Why Not:
I'm always reminded of a bumper sticker: "If you can read this, you're
too close." If you're getting butt-torped to death, you have to stop
flying into the torps. If that means not killing the other guy, then
don't kill him.
Players who do nothing but butt-torp are lousy space controllers and
are remarkably easy to clear off planets (just cloak and charge in their
general direction).
Netrek physics are such that torpedos always move at the same speed,
regardless of the speed of the ship that fired them. This means that
firing while running works to your advantage, since their torps have
a closing velocity of (12 - yourspeed), whereas yours have a closing
velocity of (12 + theirspeed) (assuming CA torps).
Various proposals have been suggested (and often implemented) over time,
including:
- "vector torps", where the firing ship's velocity is taken into
account. In the above example, the closing speed for both sets
of torps would be warp 12 if yourspeed == theirspeed. Care must
be taken to avoid giving SCs warp 28 torps. Also, butt-torping
a starbase that has you tractored becomes next to impossible.
- no torps out the rear section
- limited #of torps out the rear
- higher wtemp/fuel cost for torps out the rear
If you want to implement one of the latter proposals, you must also take
into account things like starbases (which don't really have a front and
back), and orbiting ships (they aren't running, just happen to be on one
side of the planet and not the other). These ideas weren't all that
popular in practice, because most players spin around a lot while fighting,
and even though they aren't running they are still penalized.
Some people differentiate between "runner-scumming" and "butt-torping",
though this is largely a difference in attitude rather than technique.
A1) Appendix: Sturgeon II changes
This comes from the motd (Message Of The Day) on sturgeon.cs.washington.edu,
port 2592. Other upgrade servers (and even sturgeon itself) may differ at
the time you read this; this is more for example than anything else.
[ This was added some time in late 1992, and is now very much out of date. ]
-----
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
The Experimental Server at the University of Washington, 24 hrs
UDP 1.0 compatible.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
9/14/92: NEW UPGRADES. Read on...
Borgs : Allowed, but if others ask you not to, please comply.
UDP : Supports UDP 1.0. Please use UDP clients, especially from the
UW computers Wolf, Lynx, Hardy, Shelley.
SCUM : T-mode scumming will not be tolerated. Upgrade-scumming is
strongly discouraged (i.e., please don't bring in a second
character to kill for upgrades, if you plan on playing with
others, keeping your rank, etc).
'telnet sturgeon 2591' does a ck_players.
Mail compliments (and complaints/bugreports) to ts...@cs.washington.edu
TO ENTER GAME TYPE:
[s] Scout [a] Assault Vessel (planetary)
[d] Destroyer [b] Battleship
[c] Cruiser [o] Outpost/Starbase
Press 'R' in this screen to reset your stats.
Press 'f' and 'b' to page through news and instructions.
This server has a lot of changes. I shall try to describe all the ones
I can remember making. There may be a couple more.
(1) Phasers have longer range, but damage does not decrease linearly, but
rather with the square of the range. They're faster on bigger ships.
(2) Only starbases and battleships can fire a stream of 8 photon torps.
Cruisers are limited to six, destroyers five, assault ships four,
and scouts three. Starbases have fighters too (hit "C" to toggle)
(3) Photon torpedos are identical for all ships, in terms of fuel cost,
damage, fuse, and weapon temperature.
(4) Phasers do double damage to shields, and photons double damage
to "hull" (damage points). Example: 15 point phaser hit to shields
of 20 will reduce the shields to 0 with the first 10 pts, and do 5
hull points with the remainder. Not many ships can take more than
one torp hit to downed shields.
(5) All ships can fire torps while cloaked, at 5x normal cost (300 x 5)
(6) Cloaking enemies will be revealed for a short time if (a) they get
hit by a torpedo, (b) they get hit by phasers with their shields up,
or (c) you detonate your own torpedos, to show them in a radius.
(7) Upgrades. If you refit to the same ship type, you can "upgrade"
some aspects of your ship, in return for kills. If you refit
to another ship type, you regain most of your "used up" kills.
(8) Plasma torps now "cost" 2.0 kills. They only take two seconds
to upgrade. They are "upgrade 2", and are *not* automatic for
refits from ships with 2+ kills.
(9) Scouts don't bomb; they strafe. While this is much less time
efficient, the advantage is that they can strafe until a planet
has less than TWO armies.
(A) Planets now have variable resources. Home planets (Ear, Rom, Kli, Ori)
are always Fuel/Repair/Agri, and Core planets are always Agri. Any
planet with less than 10 armies is Agri; from 10-19 it is Fuel, from
20-39 Repair, and Fuel/Repair from 40 on up.
(B) Phasers can be fired before they fully recharge. This costs the same
amount of fuel, but does less damage.
(C) The base number of kills received is equal to (Hull points of victim) /
(Your hull points). Thus, a scout destroyed by a cruiser is only worth
0.75 kills, while the cruiser is worth 1.33 to the scout.
UPGRADES
--------
To upgrade, have available kills and orbit your home planet. Refit to
the same ship type, and a menu will come up on your messages display.
Press the number corresponding to the upgrade you want. The kills will
be deducted from the number available, and your ship will be upgraded
(with some amount of refit time, depending on the upgrade).
In all menus, press 0 (or a non-number) to abort.
From the Main Menu, 1 works the same as the classic refit (fixes damage,
shields, fuel, wtemp, etemp).
Upgrades cost k1 + k2 * (previous upgrades of same type) kills, listed
as (k1/+k2), and your ship will be nonresponsive for that many seconds.
Upgrades include:
- Shields +10 pts to your shield maximum (1.0/ 0.0)
- Fuel capacity +250 fuel maximum (0.5/ 0.0)
- Fuel recharge +10 fuel/sec (0.5/+0.5)
- Max Speed +1 to maximum warp speed (2.0/+1.0)
- Acceleration +0.1 warp/sec acceleration (0.5/+0.1)
- Deceleration +0.1 warp/sec deceleration (0.5/ 0.0)
- Engine Cooling +10 engine temp cooling/sec (1.0/+0.5)
- Phasers +3 to point-blank damage (1.0/+1.0)
- Photons +1 to photon torpedo *speed* (base is 15) (3.0/+2.0)
- Weapon Cooling +10 weapon temp cooling/sec (2.0/+2.0)
- Cloaking Device halve the fuel cost (round up) (2.0/+1.0)
- Tractor/Pressor +100 tractor/pressor strength (1.0/+0.5)
- Damage Control +1 damage repair/sec (1.0/+1.0)
Commodities: upgrades that are "no deposit, no return"...
- Overload shields +50 pts to your current shields, one use only (1.0/ 0.0)
- Pseudoplasma 0 pt plasma (12) (1.0/ 0.0)
- Type 1 Plasma 50 pt plasma (12) All plasmas cost: (2.0/ 0.0)
- Type 2 Plasma 75 pt plasma ( 6)
- Type 3 Plasma 100 pt plasma ( 4)
- Type 4 Plasma 125 pt plasma ( 3)
- Type 5 Plasma 150 pt plasma ( 2)
- 10 megaton nuke Just like in Nuclear War (1 army = 1 million) (1.0/ 0.0)
- 20 megaton nuke The tables have been duplicated, except for (2.0/ 0.0)
- 50 megaton nuke the "destroy the solar system", which may (4.0/ 0.0)
- 100 megaton nuke later... (8.0/ 0.0)
Plasmas cost no fuel to fire. Nukes take up (1/2/3/4) army bays until used.
Switch between special weapons with the "C" key.
-----
A2) Appendix: Sturgeon II kill credit rules
This is included as an example for people who want to modify the kill
crediting rules.
[ This was also added somewhere around late 1992. The current "vanilla"
sources already have "fair" kill crediting included. ]
-----
(a) You can get credit, but never actual kills, for killing your teammates.
Example: F0 phasers R1, who explodes on F2. F0 gets credit for killing
both R1 and F2, but only actually gets kills for R1.
(b) Except in the case of a point-blank plasma explosion, you never get
credit for killing yourself. In that exceptional case, refer to (a).
Example: F0 oggs R1. R1 explodes, and takes F0 with him. Each gets
credit and kills for the other (posthumously)
(c) If you det someone's torp, or phaser someone's plasma, any deaths
that result are credited to you, except your own. Your own death
is credited to the person who fired the torp or plasma.
(d) If you are credited with someone's death, anyone who dies as a
direct result of that explosion is credited to you (except
yourself, as above)
-----
A3) Appendix: Extreme Netrek
From: as...@illuminati.io.com (Felix Sebastian Gallo)
Three planets; earth, rom, indi. In an equilateral triangle 1.5 screen
lengths on a side. All planets start with 30 armies; Indi has independent
armies. No pops, no agris, all planets repair/fuel. Bases regenerate
with 45 seconds remaining. Six-player t-mode, anyone can base. Standard
vanilla ships. First side to take a planet wins; after five minutes of
t-mode the galaxy resets.
Various people at various times have promised to set this up, but nobody
has yet risen to the challenge. This would, of course, bear the same
resemblance to netrek that world rugby does to LPGA golf.
A4) Appendix: How to propose a change
First of all, if it's in here, don't post it to rec.games.netrek. It's in
here for a reason: it was suggested, and died. That doesn't mean you can't
ask a server deity to add it for you; some of them are quite amenable to new
ideas (the weirder the better).
The most important item to remember is DETAIL. Describe your change in
absolutely painful amounts of detail. Include sample code at the end, if
you have it.
For example, take a look at Clever Suggestion #28 (mine dropping). I have
a list of questions that must be answered by the person proposing what, on
the surface, seems to be a very simple idea. You need to anticipate what
people will ask, and provide details for all contingencies.
A modest proposal might look like this:
- Summary: explain in a couple of sentences what you want to do.
- Explanation: explain in depth how what you're planning will work, from
a player's perspective. Don't include lists of source files, cost
estimates, or source code here; this should be readable by Admiral
Fubar, even if old Foo couldn't write a line of C to save his/her/its
life.
- Justification: explain why the world needs this change. Explain how
it will improve the game, and why it is important enough to spend time
doing it.
- Rebuttal: play Devil's Advocate, and dream up every possible objection
to your proposal. Then answer those objections. This ought to save
hundreds if not thousands of dollars by avoiding yet another r.g.n
flamefest. It will also make it easier to add to the FOCS.
- Technical stuff: if you've already made the changes or you're familiar
with the client and server, explain where you think the changes need
to be made and how much effort it will take. Include source code here
if you have it, but keep it short! If it's huge, make the context diffs
or the modified files available for FTP.
If you just have a dopey little change, there's no reason in the world why
you can't just post the code to r.g.n and say, "here's some nice code, feel
free to use it if you want." I did visible tractor beams this way, and look
at how far they've gone. (Tedd Hadley gets credit for the nice segemented
lines though.) All source code bug fixes are posted this way, usually as
context diffs (use diff -c oldfile newfile ... the order is important).
--- End of FOCS ---
Carter T. Shock
>A4) Appendix: How to propose a change
>
>First of all, if it's in here, don't post it to rec.games.netrek. It's in
>here for a reason: it was suggested, and died.
>
Hmmm... looks like the FOCS needs a little work. I can point out
a few that are implemented in most places.
Also, is there any interest in the 3 planet killer netrek mentioned
towards the end of the list? Seems a combo of the guzzler tourn.map
and a couple of well placed #ifdefs (or maybe a bot like mars and
puck?) could be implemented pretty easily. I'm willing to put it on
the to-do list after I fix the damn mars slot bug... that is,
if there's sufficient interest. (BTW: What happened to all
of those people screaming for a Sturgeon server? Player database
has maybe 80 entries in it...)
-Todd
--
|-------------------------------------------------------------------------|
| Carter T. Shock | University of Maryland |
| ct...@umiacs.umd.edu | Institute for Advanced Computer Studies |
| "Onward through the fog..." | #include <std/disclaimer.h> |