Logo5 

 Chapter 4 - Miscellaneous Stuff

Summary_Prim
[Archive]
[Links]
[Website Index]

Int_l__Netrek_League_Prim
[INL]
[INL Rulebook]

New_Player_s_Guide_Prim
[Index]
 [Chapter 1]
 > Introduction
 [Chapter 2]
 > Basic Instructions
 [Chapter 3]
 > Finer Points & Strategies
 [Chapter 4]
 > Miscellaneous Stuff
 [Chapter 5]
 > Resources
 [Chapter 6]
 > Configuration
 [Chapter 7]
 > Example .xtrekrc

Player_s_Manual_Prim
[Index]
 > [Beginners]
 > [Opening Screen]
 > [Help Sheet]
 > [Combat]
 > [Game Scheme]
 > [Galactic Map]
 > [General/Misc.]
 > [LPS]
 > [Planet Taking Hints]
 > [Robots]
 > [Tournaments]
 > [Tricky Moves]
 > [Terms]

Questions_Prim
[FAQ]

Game_Specifics_Prim
[Tactical Summary]
 > [Dogfighting]
 > [Ogging]
 > [Planet Taking Guide]
 > [Ship Index]
 >> [Ship Facts]
 >> [Ship Opinions]
 >> [Assault Ships (AS)]
 >> [Battle Ships (BB)]
 >> [Cruisers (CA)]
 >> [Destroyers (DD)]
 >> [Scouts]
 >> [Starbases (SB)]

Game_Types_Prim
[Base Practice]
[Bronco]
[Chaos]
[Dogfight]
[Guzzler]
[Hockey]
[Paradise]
[Vanilla]

Rankings_Prim
[Rank]

Software_Prim
[Clients]
[Servers]
[Utilities]
[COW Info]

 

[E-mail me]
 - leaf(a)real-time.com
 

Website hosted by:
Real Time Enterprises, Incorporated
Linux and Network Solutions

4.1 UDP, Short Packets, And SLIP

     Netrek is played over the Internet (or other TCP/IP network), which was never really designed for this kind of highly interactive, widespread gaming. Originally all Netrek games were local (on the same piece of ethernet), or at worst on the same campus (The game originated at Berkeley.) When Netrek games started being played over wider geographic regions, the lag became unbearable for players far from the server. The packets simply could not be routed fast enough for smooth play.

     At that time, Netrek was updated to support UDP (Universal Datagram Protocol) instead of TCP. This is a network protocol that runs much faster than TCP and greatly improved playability. The world was a happy place once again. The only catch is, unlike TCP, UDP packets are not guaranteed to arrive at their destination uncorrupted, or even at all! This is what makes UDP fast, but it is also a problem. In practice, it means that packets will occasionally get "lost" during play. If a server packet is lost you will have a jerky update, or a ship will appear to be in the wrong position, or a random unmoving torpedo may float on your screen, seemingly ownerless. If a client packet is lost, your phasers may not fire when you press your middle mouse button, or your shields may stay down when you order them raised.

     In 1991, the first game of Netrek was successfully played over the modem via SLIP. This was made possible via yet another modification to Netrek, Short Packets. This was an internal rewrite of the communications protocol in Netrek to use much less bandwidth. In particular, rather than sending the full positions and status of all ships and torpedoes on every update, the server sends only those things that have changed and only for those objects which are in range (i.e. on your tactical map.) It also employs clever packing of information in bit fields and variable length packets to squeeze the maximum information out of every bit. This reduced the bandwidth for Netrek to modem usable levels. However, this too had its problems: with short packets it is possible for the client and server to get out of sync with each other, as the full game status is not resent very update. This has results similar to lost UDP packets.

     However, all is not lost. If you find that your ship doesn't always respond to your commands, bring up the ping stats with the ',' (comma) key. (Incidentally, this is also where your lag is displayed: look at the "avg. rt [round trip] time" line.) Read the line labeled "tot out pkt loss". If this is greater than a few percent, UDP is losing a significant number of packets.  To fix this, bring up the UDP options window with '+' (plus). Click on the line which says "sending with simple UDP" and cycle through the various options. Try each one (enforced state, enforced weapons & state, and the last resort, TCP only) until your packet loss drops to a satisfactory level. What is actually happening here is that the client is manually tracking what you ordered, and if the server doesn't do it, resending the request.

     If you have strange garbage (random torps or phasers) on your screen or you seem to be firing at phantom ships, or your damage won't repair, or any of many strange effects, try requesting an update manually. Try the '-' (dash) key first, this requests a "small update." If this doesn't fix the problem, try the '=' key. This will cause the client to pause noticeably over a modem as the server sends more than 2000 bytes of data, including all ship positions and status, planet positions, and each player's stats, but it should completely resync the client and server. One option that I find useful in the options menu (press uppercase O) is the "request update on enter" option. When this is on, every time you enter the galaxy in a new ship, everything is updated. This causes a short pause, but it gets rid of phantom data from your previous life which sometimes happens. If you find this useful, put the line "askforUpdate: on" in your netrekrc file.

4.2 Ghostbusts

Ahh, the infallible Internet -- not! You will at some point lose your connection to the server while playing. This is called a "ghostbust". However, the designers of Netrek (those clever people!) designed a mechanism whereby the server will try to call you client back and reconnect should this happen. And it even works sometimes!

If, while you are playing, you suddenly get a freeze, try switching to the netrek console window. If you see a ghostbust message there, just wait, and hopefully the server will call you back, and you will re-enter the game. This can take several minutes, but it's better than sitting in a wait-queue. If you were very lucky, it's possible that no one will have killed you while you were disconnected.

 

 

Home_Sec 

Website_Index_Sec