SERVER SECRETS ---------------------------------------------------------------------- From: kluge@ccwf.cc.utexas.edu (Alex Kluge) Newsgroups: alt.games.xtrek Subject: Foghorn back up (I think) Date: 20 Oct 91 09:21:21 GMT The netrek server sometimes has problems killing the shared memory which it uses. It turns out that this can be fixed with an ipcrm command on a unix system. ie ipcrm -M KEY where key is an ID which tells the system which memory segment you want to kill - see the daemon source for the key on your server. I am bothering to post this as I have seen the same problem on at least two other servers, and this might be of use to someone somewhere in the future. Blasting away again, Alex Kluge ------------------------------ From: bav@hobbes.ksu.ksu.edu (Brick Verser) Newsgroups: alt.games.xtrek Subject: Re: Server Date: 9 Nov 91 02:47:41 GMT In article <8542@gazette.bcm.tmc.edu> mparsons@fleming.iaims.bcm.tmc.edu (Mark Parsons) writes: > . . . or is there very little file accessing done by netrek?? A netrek server is pretty easy on disks. >Also, have any of you GODs looked at the effect of netrek on your >department/organization's network, i.e., loading down the network. A T1 line isn't going to notice much of a burden. Don't do this to your 56KB line, though, if that's all you've got. >If/When I get this server up and running, I'll post the info. For those of >you who miss flubber (is it coming back???) you may be glad to know that >I'm in Houston . . . Anyone considering running a server on a Sun workstation smaller than a Sparc2 should think hard. The little Suns can only speedily switch between 8 contexts, and every netrek player (and robot) counts as one. The game slows down very noticably at the 8 player point and continuing to use the workstation interactively with 12-16 players going will test your patience. Larger Suns do better. I don't know how well endowed DEC/SGI/IBM boxes are. A netrek server does little disk I/O, doesn't use a lot of CPU, and won't overtax a T1 NSFnet connection. But it'll do a gazillion context switches per second and keep the working sets of each of the tasks in memory. Don't try sneaking this onto a machine hoping the sysadmin won't notice. --Brick ------------------------------ From: hadley@osiris.ics.uci.edu (Tedd Hadley) Newsgroups: alt.games.xtrek Subject: Re: Who's on the servers all day? Date: 7 Nov 91 00:23:42 GMT In <1991Nov6.204047.4874@sbctri.sbc.com> clay@sbctri.sbc.com (Patrick E. Clay) writes: >OK, so what the heck happened to the servers at flubber and elsewhere >all of a sudden? The "chaos" server hasn't responded in 2 days, and >flubber has been choked with a wait queue since 11/5/91 afternoon. >I tried to sign on at 7:30am this morning and have been sitting at >position 6 now for 7 hours with no change. I'm not 100% sure about this but I don't think anyone is/was playing on flubber. I did 'rup flubber.cc.utexas.edu' and got back load averages close to 0.0 most of the day. (Typically with 7-8 players the load average jumps beyond 3). So, what is this? A kludge to keep people out? Two better suggestions: set MAXLOAD=0.0 in .sysdef (let's people log on but not play) or 'touch .access' (results in client message "Sorry, but you cannot play xtrek now. Try again later." until .access removed) Isn't this better than having 10-20 people stuck in the server queue all day long? (Maybe I'm missing something) (I believe .access also supports selective play with strings of the form [hostname] [y/n].) ++ Tedd Hadley (hadley@ics.uci.edu) ------------------------------ From: fadden@uts.amdahl.com (Andy McFadden) Newsgroups: alt.games.xtrek Subject: XShowGalaxy v1.0 on pittslug Date: 15 Jan 92 19:24:19 GMT Okay, I put xsg v1.0 in the incoming/ directory of pittslug.sug.org. This should be the last update for a while. New items since v0.9 include the ability to knock players out of orbit, to change their team, and some support for scanning beams (just some fiddling with constants and sysdefaults.c, actually). Here be the README. ===== XShowGalaxy v1.00 README By Andy McFadden (fadden@uts.amdahl.com) WHAT IS XSHOWGALAXY? This is essentially an X version of the "showgalaxy" utility which comes with netrek. It can only be used by Netrek (Xtrek II) server operators, because it accesses the Netrek shared memory segment directly. It has a number of improvements over the original "showgalaxy", including: - galactic and tactical displays on same screen - more detail, since it's X instead of curses - ability to lock onto a player or planet - ability to move around the game board as if you were playing (at up to warp 40 though) - ability to change player status, including: - player name (reset when they get killed) - team (F/R/K/O/I) - ship type (yes, instant refit on the fly, with shield/damage/fuel scaled proportionately; robots will retain any special abilities, like free torpedos and phasers) - shield/damage/fuel; options are heal (cure all, including wtemp/etemp), help (cure 10%), harm (damage 10%), and hose (damage fully - barely alive) - number of kills (+/- 1) - lower shields (kinda fun if timed correctly) - knock out of orbit - ability to nuke (as with xtkill) or eject (forced self-destruct) - ability to modify planets, including: - planet name - ownership - special features (fuel/repair/agri) - number of armies (+/- 5, or Destroy) - ability to move players and planets to an arbitrary location (this does tend to freak people out though) - visible tractor/pressor beams - continuously updated player/planet display - larger "all messages" display, with optional message beep when a message sent to GOD is received - some of the Options from Netrek, including update frequency, choice of planet bitmaps, view kill messages, show tactical planet names, and show shields - standard netrek Info dialogs (both 'i' and 'I') - optional support for Galaxy and AT&T ships - most of the items in the Options menu can be set in $HOME/.xsgrc (including updates/second, show shields, what to show on the galactic map, and whether or not to display xsg's "position") - uses the netrek ".sysdef" file for things like PLKILLS It also has everything that showgalaxy had, including the ability to send messages to players. While you shouldn't be mucking around with people while they're playing a serious game, it can prove invaluable when you want to test certain features (you can damage robots, switch to an SB without having to play with .sysdef, try fighting an SB Guardian, etc, etc.) It's also possible to completely re-sculpt the galaxy; you can rearrange all the planets, rename them, reassign them fuel/repair/agri at will, etc. Sort of a Netrek Galaxy Editor really. COMPILING/INSTALLING: For best results, put this in the netrek source hierarcy (i.e., netrek/netrek/ netrek/ntserv/ ... netrek/xsg/ I use a symbolic link to ../netrek/bitmaps.h and ../netrek/oldbitmaps.h; didn't see any reason to transfer 230K of data around when you've already got them on your system. I also figured that some systems might have customized bitmaps. If you don't have your directories set up like mine, just copy the headers or symlink them into the xsg directory. You will have to do a minor customization to "defs.h"; the definition of SYSDEF_FILE will have to be changed to whatever is appropriate for your system. This ought to compile without problems on anything that will run netrek. There is a section at the start of the Makefile which has a bunch of flags for BSD/SYSV systems, ATT class ships, Galaxy class ships, and scanning beams. Make sure these are defined correctly for your system before you try to compile. I distributed this with x11window.c, but it should work equally well with x10window.c or glwindow.c. Should. I don't have a setup where I can test them, so if you can verify that it works, tell me. To use this program, just run "xsg" (when the daemon is up) on the machine that the server is running on. Since xsg accesses the shared memory segment directly, you MUST be on the same machine. The help screen (hit 'h') shows all of the commands. It reads a few defaults from $HOME/.xsgrc (show shields, message beep, window stuff). KNOWN BUGS/GLITCHES: (most of these are inherent in the Netrek client or server, so I can't fix them) - When you change ship types, the shield/damage/fuel status bars are re-scaled, but they aren't erased before they're redrawn. This can leave a splotch on the status display. (Note this can also happen normally in the game if you refit while partially damaged.) - Moving planets around causes the galactic map to get smeared (in the clients only; xsg redraws the screen automatically). Refreshing the screen should remove the smear. - You can't move a player who is orbiting a planet. On the other hand, if you move a planet, all orbiting players move with it. The "knock out of orbit" item on the "modify player" menu should be used. - Netrek uses a 40x40 grid to determine which planets need to be redrawn on the galactic map. If you put them too close together, the higher-numbered planet may become erased from the galactic map when somebody flies over it. - Name changes to planets don't propagate to clients. - The playerlist will show old data or possibly garbage as players are entering. This is best fixed by fixing grabslot() in ntserv/enter.c to put "-" into p_name, p_login, and p_mapchars (two different places in the routine). - There are conflicting definitions for Galaxy class cruisers (even the most "current" definition of the sources I grabbed had different #of max armies in netrek/getship.c and ntserv/getship.c). When you change a ship type, xsg will use whatever numbers are compiled into it. If you have a different or modified getship.c, you'll have to substitute it in. You may also have to substitute sysdefaults.c if your ship defs depend on "chaos" mode or some other feature. (While it's not true in general, you should be able to simply copy your getship.c over the xsg copy. If you want to use your sysdefaults.c, you may need to add some definitions to data.h and data.c.) - Every great once in a while, the program will crash and report an X protocol error (i.e., something in x11window.c passed a bad value). I'd suspect the X code, but I'm using the same routines that the game does. The error occurs at random, so there isn't much I can do about it (I suspect uninitialized data, but there's one hell of a lot of data used by this program...) THAT'S ALL, FOLKS... Please let me know if you find any bugs, or would like to see a certain feature. For bug reports, it's easiest to find them and fix them if you tell me how to make them appear. ------------------------------ Newsgroups: alt.games.xtrek From: terence@bronco.ece.cmu.edu (Terence Chang) Subject: Clarification on bronco server mods. Summary: Player's summary of changes made to bronco/rwd4 from distribution. Date: Thu, 23 Jan 1992 20:54:12 GMT Since there's some discussion about unifying client/server code, and also some discussion about "fixing" "Netrek", I thought I'd post a list of changes that have been made to bronco/rwd4 that are visible to players. If the server admins on Tom's list want to mail me "player's summaries" (or post them), I/somebody can compile them into a "Server Hopping Guide". A comment about Tom's server list: The "standard bronco setup" only applies to bronco/rwd4 as far as I know. The other servers I assume are using standard scam source. Terence -- Cut here -- Changes are listed in rough order of impact on game play. Player's Guide to rwd4.mach.cs.cmu.edu ====================================== Last revised 1/23/92. * See guide to bronco.ece.cmu.edu (there may be negligible differences). * When borgs are allowed (borg query is available, see bronco): vector speed torps, and rearward fired torps have large wtmp penalty. Player's Guide to bronco.ece.cmu.edu ==================================== Last revised 1/23/92. * Surrender countdown. T-mode only. When a team is reduced to ownership of 1 planet, countdown is initiated (presently at 45 minutes). If team gains ownership of 2 or more planets, countdown is suspended (but not reset). If team gains ownership of 4 planets, countdown is terminated. While team has ownership of only 1 planet, countdown runs down in real time. When it expires, the team is genocided (surrender), and team's last planet is neutralized. * HunterKillers (aka Iggy) (see server robots). Appears every 15 minutes in a random location near the center of the galaxy, announcing time of day and queue size. Hostile to all players. Is polymorphic: assumes ship class of nearest enemy, shields/damage are scaled proportionately when changing ship class, adjusts warp while maneuvering according to ship class. Goes away when killed. * Terminators (see server robots) for planet taking out of T-mode. Neutralizing a planet located in the beamer's home quadrant produces a Terminator if T-mode has been gone for 15 seconds, and two Terminators if the planet is outside the home quadrant. Does not polymorph, but is hostile to target's team and preferentially seeks out the target. Has a max warp of 10 and unlimited etmp in order to pursue targets of all ship classes. Goes away when target leaves the game or when Terminator is killed. * Terminators for players on a non-warring race. T-mode only. Once T-mode begins, after a random delay of several minutes, a Terminator will target any players that are not on a warring race (once these players die, the distribution server code forces them to join a warring race). Goes away when target switches teams or when Terminator is killed. * Guardians for bombing out of T-mode. If T-mode has gone for 15 seconds, a guardian robot can appear in response to bombing even if the planet's race is represented by players. (Distribution code produces a guardian robot when bombing a planet located in a team's home quadrant which is owned by that team and no players on are that team). * Server robots. Have sub-optimal tractor/pressor code. If damaged: Will not repair while sitting on top of a hostile planet, and will orbit the nearest repair planet if it is friendly. Robots are do not count towards T-mode. * Torps. Torps that hit galaxy boundaries only damage hostile ships (no wall kills). * Messages. Players can selectively ignore messages (to All, to Team, or individual) from other players. See server motd for usage. * Kill messages. Displays number of armies on board when a player dies. * Cyborgs. The server will list non-blessed clients if you send a ":" to yourself. Sends less that the usual amount of player flags to clients, especially on "inviso" players. * Players entering the game. The maximum allowed delta in the size of T-mode teams is 1 instead of 2 (player may choose between the two teams only if they are even in size). * Resource distribution. Not more than 3 agris can exist in any one quadrant (there was a bug that kept this from working that I just fixed, fortunately 4+ agris is pretty rare). * Lock outs. The server can reject logins from certain user names. * Restricted hours. Server accepts connections 24 hours a day but allows players past the motd (message of the day) screen only during certain hours. Motd includes the bronco's local time when the connection was established, for those trying to get in right when the server opens. * Supported but not used: planet movement; a fix for the "two players/one slot" bug; faster turn rates (from sequent); no rearward torps restrictions. End of Player's Summaries. ------------------------------ From: fadden@uts.amdahl.com (Andy McFadden) Newsgroups: rec.games.netrek Subject: Updated tools.doc Date: 20 May 92 19:09:26 GMT I merged the bronco tools in with my own, and decided to add descriptions of the bronco stuff to the tools doc. Terence added some cool stuff to the tools... Hope this doesn't become too complicated and confusing. Oh well. ----- Admin guide to the Netrek tools and dot files. Andy McFadden (fadden@uts.amdahl.com) Last updated 20-May-92 Everything applies to the scam sources, except where noted with "**", which are local enhancements. Bronco enhancements are noted with "bronco:". ============================================================================== Commands ============================================================================== makescores ---------- Usage: makescores Sends "scores a" to "scorefile.a", "scores s" to "scorefile.s", and "scores A" to "scoredb". It then runs "trimscores" using "scoredb" as input, and sends the output to "players.old" (which will get a brief description of the players which were deleted). message ------- Usage: message Allows you to send a message to any player. You will be prompted for a message (80 chars max) and a recipient (same characters 0-9a-jAFKRO as in the game). Note that it sends a "raw" message; you have to supply the "GOD->R3" part yourself. bronco: mess ------------ Usage: mess Like message, only you can enter multi-line messages, which get sent in a batch (so you don't have to keep running "mesage" over and over). Also allows multiple recipients (so you can send to "0123" instead of just "0"). newscores --------- Usage: newscores < scoredb (don't run while people are playing) Regenerates the .player database. "scorefile" should be the output of "scores A". The .player database is overwritten. Note that the .player database is updated by ntserv, and can get really screwed up if you change it while the game is running (especially if you delete a player). ** nuke ------- Usage: nuke (don't run while the daemon is running) Removes the shared memory segment. Useful for when the daemon dies but the segment is still there. (Normally the daemon destroys the segment when it quits, but if it crashes, the segment will remain.) planets ------- Usage: planets List all planets with some general info about them. Useful when you want to see if the daemon generated a reasonable set of planets. bronco: pl3 ----------- Usage: pl3 [seconds] Sets "Top Gun" mode, where torps do 130 damage, plasmas are freely available, and starbases can be brought out continually. Automatically turns it off when time expires. Don't forget to configure the save file (default is /usr/users/terence/xl/.sysdef.topgunrestore). Note that CA has torpturns=2, and BB/AS have torpturns=3. players ------- Usage: players [d] List people playing the game. The "d" flag will display kills, damage, shields, armies, and fuel (currently a restricted mode). ** New "c" flag continuously checks the game for players, and reports a count. Useful if you're waiting for people to sign on. bronco: new 'r' flag shows ratings and status (ghostbust slot) stuff. The status codes are Free, Outfit, Alive, Exploding, and Dead. resetplanets ------------ Usage: resetplanets (don't run while people are playing... it will work though) Resets galaxy to default setup, with 30 armies per planet and original owners. bronco: setgalaxy ----------------- Usage: setgalaxy [l|r|t|f|F|n] Replacement for resetplanets. Allows you to reset just locations, just armies, rename planets, etc. Run with no args for usage info. scores ------ Usage: scores [aodbprstgAOD] a - print best players in order o - list players with best offense d - list players with best defense p - list players with best planet rating b - list players with best bombing rating s - list best starbase players D - list players with DI ratings [ for the above, players with <1 hour or >4 weeks of non-play are omitted ] r - list all players, hours, and ratings t - print rough number of seconds of play time g - print stats for all players, with breakdown by non-tournament, tournament, and starbase A - list entire database in ASCII form (for use with newscores) O - print players who haven't logged in for 4 weeks bronco: new 't' option - list players with best total ratings. The old 't' option has been moved to 'T'. The format for "scores A" is: (top line: total time, planets, bombing, kills, losses, timeprod?) name password keymap........................................ ..............................................rank nt-maxkills nt-kills nt-losses nt-armies nt-planets nt-ticks t-kills t-losses t-armies t-planets t-ticks sb-kills sb-losses sb-ticks sb-maxkills lastlogin flags The spacing may be important (especially the first few fields; if you change a name, make sure the password lines up correctly). ** See also the "pledit" utility, available via anonymous FTP. showgalaxy ---------- Usage: showgalaxy [-d##] A curses-based tool to watch the galaxy. The -d option allows you to set the number of frames per update (default is 10 == 1 update/second). ** default is now 5 (2 updates/second) Commands are: f - full screen view (use this to un-zoom or un-whatever) m - send message (press a key for destination (AFKRO0-9abcdef), then type message. ESC exits this mode without sending anything.) z - zoom in (follow with player number) P - show list of planets L - show list of players (hit space bar to toggle info screen) ^L- redraw (there seems to be some VT-100 specific stuff here) . - ** panic button (clears the screen, waits for keypress) ** See also the "xsg" command, available via anonymous FTP. bronco:stat ----------- Usage: stat Displays some stuff from the "status" struct. Don't worry about it. trimscores ---------- Usage: trimscores [mercy] Trims away players which don't seem to be active. Higher ranks will be preserved longer than lower ranks. The larger "mercy" is the fewer people will be cut; the default is 10. 4 is good on an active system. bronco: wander -------------- Usage: wander Apparently incomplete attempt to make the core planets circle the home world. Try "wander -R" for Romulans, etc. You can specify a movement increment with "-i". The "-d" flag mentioned in the usage string doesn't seem to be handled. There are three of these, wander.c, wander2.c, wander3.c; if you feel like playing around with them, go ahead, but you're on your own... watchmes -------- Usage: watchmes Continually display all messages sent in the game. bronco: supplying an argument (anything) causes certain messages to be filtered out. This makes it more suitable for logging (note that "tee" and "tail -f" won't work because of output buffering; just use two watchmes processes or a utility like showgalaxy or xsg which displays messages if you want to see them and log them at the same time). xtkill ------ Usage: xtkill player "Utterly obliterates" a player by "divine mercy." Player is not kicked out of the game, just nuked in a big way (the starbase explosion is used). Note that "player" is a NUMBER; currently a-f is not supported (it uses atoi()). bronco: lots of new options. Usage: xtkill {0-9a-j} [mode[mode option]] e - eject (original xtkill purpose; the default if no mode is specified) s - ship class [abcdosA] (change to new type of ship) t - teleport [frkoc] (race or center) S - Super (lots of shields & damage) T - Team [frko] (change which team the player is on) D - Demote (drop one step in rank) P - Promote (bump up one step in rank) F - Free slot (free up a ghostbusted slot - no player but still blocked) k - kills increment (give them free kills) h - harm (remove shields and make them 50% damaged) C - Coup? Sets the surrender timer to a low value (6) Keep in mind that the ship changes use an internal version of "getship.c" which may or may not match your own. The ship change also appears to grant plasmas. Note that programs like "watchmes" and "showgalaxy" may become confused if the daemon exits (usually because nobody has been playing for 60 seconds). It is usually necessary to restart the program. ** UTS showgalaxy now watches for the daemon to die and come back, so you can leave it running between sessions. ============================================================================== Dot Files ============================================================================== .access ------- Controls access from specific machines. People who are denied access will simply be dropped. A sample file might look like: default y amdahl n .conquer -------- Whenever a team genocides another team or conquers the entire galaxy, a report is appended to this file. .global ------- Raw data file; contains global statistics for tournament mode usage. Don't modify. The data stored here represents the TOTAL #of ticks of play, the total #of armies bombed, etc, etc; it's used for determining ratings (and therefore DI). .motd ----- This is the message displayed when you sign on (news & instructions). Each screenful is 28 lines long; I use line 28, 56, etc as a "next page is..." line. .planets -------- This keeps info on planets between games. Stores the current #of armies, current owner, whether a planet has fuel/repair/agri, etc. If you truncate the file, a new set of planets will be generated the next time the daemon is started. If you remove the file, a new set of planets will be generated EVERY TIME the daemon is started (daemonII only updates the file; it doesn't create it). If the game is running but you want to have it re-shuffle at a later date, remove the old file and touch a new one. Truncating the existing file won't work, since the daemon has it open and will re-write the info before it exits. .players -------- The actual player database. Raw data; access with the "scores" command. .sysdef ------- System definition constants; allows you to change various features. This is the most interesting of the dot files... A typical file looks like: TOURN=4 SHIPS=SC,BB,DD,AS,CA,SB WEAPONS=PLASMA,TRACTOR PLKILLS=2 SBRANK=3 PLANETS=00,10,20,30 CONFIRM=1 HIDDEN=1 MAXLOAD=100.0 CHAOS=0 UDP=1 TOURN is the #of players required per side for tournament mode. The default is five. Changing it to nine effectively disables tournament mode. SHIPS is the allowable ship classes. ** Add GA for Galaxy class ships, and ?? for ATT ships. WEAPONS specifies special weapons. Currently PLASMA and TRACTOR are allowed. ** Now SCANNER allows scanning beams. PLKILLS is the #of kills required before you can refit for plasma torps. SBRANK is the minimum rank required to drive a starbase. Ensign is 0. PLANETS specifies a list of possible starting planets. Every time someone enters the game, a planet in their space is chosen at random from the list. If there aren't any listed, their home planet will be used. This implies two things: it is possible to have more than one start planet, but it is impossible to start in foreign space. CONFIRM is a boolean flag; if 1, then the server will attempt to verify that the client is not modified (see "reserved.c"). ** If 2, then cyborg clients can pass the word "Cyborg" for the verify packet and be accepted. HIDDEN is a boolean flag. If 0, hidden mode is turned off (you can see all players on the galactic map). If 1, it's activated for tournaments. ** If 2, it's always active. MAXLOAD is the maximum load average allowed before the game shuts itself down. ** Under UTS, if MAXLOAD is set to "0.0", then the game will shut down. No comparison with the actual load averge is performed. CHAOS is a boolean flag; if TRUE, then "chaos mode" is turned on. This has the following effects: - you can join any team at any time, without having to quit. Self destruction does not force you out. - the only restriction on who can have a starbase is rank (you can have as many as you want, you don't need 4 planets, no time delay, can be alone). - starbases move at warp 3, and don't have problems with weapon temperature. ** UDP sets UDP mode. 0 turns it off, 1 turns it on, 2 enables connect-message debugging, 3 enables verbose debugging. Note that these changes can be made while the game is being played. So, you can switch to CHAOS mode and drop SBRANK, become a starbase, and change it back before anybody else can do anything. The game DOES print the message "The rules of the game have changed", so that people will be aware that something is different. ------------------------------ From: fadden@uts.amdahl.com (Andy McFadden) Newsgroups: alt.games.xtrek Subject: XSG v1.1 on pittslug.sug.org Date: 27 Mar 92 00:47:12 GMT XShowGalaxy v1.1 is now on pittslug.sug.org, and should be available as soon as it gets moved out of incoming/. Exciting new features: - ability to "pacify" players (resets hostile and war status) - mouse warp to message window ('m') - movement key changed to 'r' (I kept hitting it when I wanted to send msgs) - aware of "UDP" keyword in .sysdef files For those who don't know about xsg, it's a server-admin tool (i.e. you can't just crank it up on a remote workstation) like the curses "showgalaxy" utility. However it's X-based and does a whole lot more (you can rearrange the galaxy with it, for example). ------------------------------ Newsgroups: rec.games.netrek From: terence@bronco.ece.cmu.edu (Terence Chang) Subject: Re: "bomb out of t-mode" ? Date: Thu, 2 Apr 1992 20:48:39 GMT In article <72324@netnews.upenn.edu> paulsen@widget.seas.upenn.edu (Brian Paulsen ) writes: >There can be no confusion of whether it is tmode or not. Also, tmode starts >when the 't' flag is shown. The reason it takes about 5 seconds (sometimes) >is that the new player is forced to pick the team which would make tmode. >However, until he actually clicks on that square, tmode hasn't really started. >Any server gods want to back me up on this? Robot writers should know also. Um, let's start over. 1. T-mode starts and ends with the messages about Dan Quayle et al. 2. There is an obscure server bug that on rare occasions will leave some clients' "t" flag stuck on when t-mode ends. As far as t-mode goes: the daemon checks every 0.1 seconds to see if there are TOURNPLAYERS on two or more teams (as specified in .sysdef) (see tournamentMode(), called by move()). If this does not agree with status->tourn (_the_ boolean which says whether or not t-mode is on), then the cute message is sent to ALL, and status->tourn is updated. Therefore status->tourn (and t-mode) is synchronized with the message. Now, it is ntserv's responsibility to propagate the value of status->tourn to its client process. This is how (see ntserv/socket.c): updateStatus() { /* Update status every 10 seconds? */ if (repCount % efticks(50) == 0 && ntohl(clientStatus.timeprod) != status->timeprod) { clientStatus.type=SP_STATUS; clientStatus.tourn=status->tourn; This is the idea: every 10 seconds, update the client's status->tourn value (plus other values that are used to compute ratings/DI). But, don't bother updating if the status->timeprod has not changed since the last status packet was sent (timeprod is incremented every 0.1 seconds, if it is t-mode, by the number of players in the game). Note a bug here (remember that the daemon and ntserv operate asynchronously on shared memory) given the following events: 1. T-mode is on. daemon updates status->timeprod. 2. ntserv sends status->tourn, status->timeprod etc, and waits 10 seconds. 3. T-mode ends. daemon sets status->tourn to 0. 4. 10 seconds later, ntserv notices that status->timeprod is unchanged, and _never_ sends new status->tourn value. (BUG) The reason this bug doesn't show up often is that the usual sequence of events is 2, 1, 3, and everything works. There is approx 0.1 sec between 1 and 3, so I'd guess there's a 1 in 100 chance of failure per client per end of tmode. This is what we really want: updateStatus() { /* Update status every 10 seconds? */ if (repCount % efticks(50) == 0 && ((ntohl(clientStatus.timeprod) != status->timeprod) || (clientStatus.tourn != status->tourn))) { /* bug fix 4/2/92 TC */ [ Update the client's status if the timeprod or t-mode status has changed in the last 10 seconds. ] [ If I made a mistake somewhere feel free to correct me. This bug is real -- I've seen t-mode flags stuck on many times. ] Terence ------------------------------ From: fadden@uts.amdahl.com (Andy McFadden) Newsgroups: rec.games.netrek Subject: Re: Galaxy Servers Date: 8 Apr 92 23:50:06 GMT Top 10 abuses of XSG: 10. "why does my pseudonym read 'Ensign Butthead'?" 9. "how come I'm flying backward?" 8. the "infinite shields" effect 7. the "instant starbase" manuver 6. "why is the planet I was refueling on doing damage to me?" 5. "Hoser declaring peace with All" 4. "why am I going warp 1... hey, my shields... what the hell?" 3. "why do my shields always turn off right before I get hit?" 2. "why does attempting to drop armies on a planet make me peaceful?" 1. "what the HELL is Klingus doing right next to Romulus?!?" ------------------------------ Newsgroups: rec.games.netrek From: terence@bronco.ece.cmu.edu (Terence Chang) Subject: Att'n server admins: scores/newscores/trimscores/Pig borg problem Date: Fri, 10 Jul 1992 11:17:40 GMT Symptoms of Problem: ------------------- * Pig borg characters get their stats mysteriously screwed up -- most conspicuously a loss of rank. * Lots of corrupted data appears in the player database, usually after a Pig borg character. Problem: ------- Well, it's a long story, and it goes something like this... Pig borgs use nonstandard keymaps. As far as the server is concerned, a keymap is a 96 character string that usually looks like: !"#$%'()*+ ... xyz{|}~ but a Pig keymap will look like: ^A^B^C^D^E^F^G^H^I^J^K^L ... [\]^ This causes the server no grief as far as retrieving, using, and storing the keymap is concerned. However, the usual method for scrubbing the player database is to use the two tools "scores" and "trimscores" as follows: scores A > scoredb trimscores 5 < scoredb The problem is that "scores A" will put a raw ^J into the scoredb file. "trimscores" and its companion tool "newscores" both use gets() to read scoredb back in a line at a time, since scoredb is a variable-width ASCII dump of the database). There is a possibility that the Pig keymap's ^J will be misinterpreted as a newline character. When this happens, the stats from the player previous to a Pig will be used when the Pig entry is rebuilt -- recycling rank, hours, etc. The fix: ------- Either: 1. Don't allow borgs*. 2. Don't scrub your database*. 3. Delete all Pig characters before scrubbing*. 4. Modify your server to disallow funky characters in your characters' keymap (32 - 127 is the normal range). 5. Hack "scores.c" so that it doesn't print ^J (see the function fixkeymap(), which already weeds out null chars). * = light-hearted solution Terence ------------------------------ From: hadley@thoth.ics.uci.edu (Tedd Hadley) Newsgroups: rec.games.netrek Subject: XSG 2.01: updates/bug-fixes to XSG 2.0 Date: 1 Mar 93 15:59:55 GMT To summarize: lots of compatibility problems (gcc, sysv, etc) fixed, more rigorous error checking, all bitmaps now included and used (if ship type defined by server), and a few new features (see below). XShowGalaxy v2.0.1 now on pittslug.sug.org:/incoming/xsg2.0.tar.Z, will replace /pub/netrek/xsg2.0.tar.Z ftp.cis.ksu.edu:/pub/upload/xsg2.0.tar.Z, will replace /pub/Games/netrek/xsg2.0.tar.Z NOTE: same name, only the dates have changed. If you have a working (or near-working) copy, as an alternative to downloading the new tar file, I'll also post a patch to the existing xsg2.0 source (Subject: XSG 2.01: patch). BUGS FIXED - removed string-constant writes in defaults.c. Was causing segv when compiled with gcc. - zero'd the frame initialization during playback. - added better checking in dmessage.c for bad messages - added setvbuf and newer libraries in Makefile for SYSV (thnx Nick Trown). - simpler GALAXY/ATT/IGGY scheme -- no Makefile symbols, detects if GALAXY and/or ATT defined. All bitmaps defined. NEW FEATURES - added ghostbust and free slot menu options for modify-player - added ability to select players or planets from player/planet list. - added 'godsname' variable to configuration file and entry in options menu to set something other then "GOD" when you send messages. SERVERS TESTED - bronco-final - INL3.98 - doorstop server - calvin server MACHINES/OS TESTED - sparc 2 SunOs 4.1.2 - hp9000/800 HP-UX (sysV) - dec5000 ULTRIX V4.2 KNOWN PROBLEMS - record files are not compatible across different servers if the struct.h's differ (i.e. record file from INL3.98 xsg will not work on xsg compiled for bronco-final). The solution for now: recompile xsg with the struct.h used in the record file. Eventually a struct.h-independent record file format should be developed. - some servers occasionally construct a message over 80 chars which overwrites the 'm_from' field of that messages struct. This was causing xsg to crash before; now increased checking avoids the crash and an error message is reported. Thanks to Nick Trown for tracking this down. ------------------------------ From: bharat@shadow.Eng.Sun.COM (Bharat Mediratta) Newsgroups: rec.games.netrek Subject: Re: BRONCO: Strangeness with the server. Date: 24 Mar 1993 21:48:32 GMT In george@ece.cmu.edu (George Cebulka) writes: >I have also noticed that the sometimes if I free a slot via xtkill x F, >that the player still can not get in immediatly. They end up on the wait >queue, with a queue size of 0. There have been other times, when I have >attempted to free slots using xtkill x F that the slot will not free up, >even with repeated applications of xtkill. If anyone has an idea of what >could be causing this or a possible solution, I'd like to hear it. I find that if I do an 'xtkill x; xtkill x F' it wastes the process and clears the slot almost every time. The first one makes sure that ntserv (unless it's terminally hosed, which is rare) quits, and the second one clears the slot. -Shade ------------------------------ From: hadley@cad.ics.uci.edu (Tedd Hadley) Newsgroups: rec.games.netrek Subject: Re: BRONCO: Strangeness with the server. Date: 24 Mar 93 17:26:06 GMT In george@ece.cmu.edu (George Cebulka) writes: >I have also noticed that the sometimes if I free a slot via xtkill x F, >that the player still can not get in immediatly. They end up on the wait >queue, with a queue size of 0. There have been other times, when I have >attempted to free slots using xtkill x F that the slot will not free up, >even with repeated applications of xtkill. If anyone has an idea of what >could be causing this or a possible solution, I'd like to hear it. You have to kill the corresponding ntserv process before the slot can be freed. Otherwise ntserv will continue to undo the xtkill: (some places in getentry.c) if (me->p_status == PFREE) { /* xtkill would do this */ me->p_status=PDEAD; /* whoops, ntserv says no way */ me->p_explode=600; } The problem then is figuring out which slot is which server process. I've submitted this routine for the next INL patch which creates a slot number file with the process number in it (similar to a lot of unix daemons). Thus ./slots/0 has the process number for player 0, ..., ./slots/f has the process number for player f. The routine should be called just after a slot number is allocated by findslot() in main.c #define SLOT_PID_DIR "slots" /* probably move to defs.h */ make_slotpid_file(pno) int pno; { FILE *fo; char buf[256]; (void)mkdir(SLOT_PID_DIR, 0700); /* xx -- ignoring errors */ sprintf(buf, "%s/%c", SLOT_PID_DIR, shipnos[pno]); if(!(fo = fopen(buf, "w"))){ perror(buf); return; } fprintf(fo, "%d\n", getpid()); fclose(fo); } ( From there it's conceivable xtkill could be patched to read the slot process number, kill() it (if it exists) and then free the slot.) ++ Tedd Hadley (hadley@uci.edu) ------------------------------ From: fadden@uts.amdahl.com (Andy McFadden) Newsgroups: rec.games.netrek Subject: Re: Tar & Feather him Date: 1 Jun 93 18:27:46 GMT In article books@mailer.cc.fsu.edu (Roger Books) writes: >I would assume the ability to lock out players still exists. Where does this myth come from? You can lock out hosts and pseudonyms, but not people. ------------------------------ Newsgroups: rec.games.netrek From: dgosseli@cs.ulowell.edu (Dave Gosselin) Subject: Announcing: A Vanilla server release Date: Thu, 17 Jun 1993 20:51:31 GMT I've just put four files on pittslug.sug.org and crissy.berkeley.edu in /incoming. vanilla.crypt.readme vanilla.readme vanilla.rsa.v.01.00.pl.00.tar.Z.crypt vanilla.v.01.00.pl.00.tar.Z They contain a new version of the standard netrek server. It is an attempt at getting a single set of server code to allow the server gods easier access to new mods. If there is one distribution that people start from things like short_packets will be more quickly distributed. I would like to volunteer to maintain a patch list and periodically put updated versions up for ftp, so I encorage you to send me any bugfixes/patches or nifty new features. I started with the bronco.final patch level 7 version of the server (which contains short packets) and added the following mods: RSA support (including the # message) Ping support Path choice support Comments in sysdef (using #) New message flagging SINL 93 pops SINL 93 resources SINL 93 planet layout I've also tried to clean up the installation process a bit (taking my cue from the INL server). I think it is a fairly decent set of code, let me know what you think. The vanilla rsa file contains a few mods to fit the newer format as well as rsa_clientutil.c, it has been crypted using the same key as the original distribution. dave ------------------------------ From: hadley@cad.ics.uci.edu (Tedd Hadley) Subject: Re: Doorstop? Newsgroups: rec.games.netrek Date: 25 Jun 93 18:58:12 GMT Hint for people with core-dumping daemons who don't have time to reproduce the problem: put this in freemem() somewhere (I have it near the end right after the shared memory segment is removed): switch(sig){ case SIGSEGV: case SIGBUS: /* optional case SIGILL: case SIGFPE: case SIGSYS: */ (void) signal(SIGABRT, SIG_DFL); abort(); /* get the coredump */ default: break; } compile with -g (gcc -O -g is nice because you can get optimized performance and still be able to use the debugger) (if SunOS you may need to link with -static (-Bstatic for suncc)) and the next time it crashes you'll have a core file. ++ Tedd Hadley (hadley@uci.edu) ------------------------------ From: mhl@space.mit.edu (Eleazor) Newsgroups: rec.games.netrek Subject: Re: getting RSA keys for servers Date: 7 Jul 1993 15:11:32 GMT If you have the keycomp utility, for example from Dave's Vanilla server code release, the following shell script can be used to update your keylist painlessly (I call it newkeys); it makes backups all along the line so you can manually back out any changes by moving the ~ files back, and you can still use an exclude file -- it mostly comments out the lines from telnet that choke keycomp and cause a core dump: #!/bin/csh -f rm -f keys.dat~ mv -f keys.dat keys.dat~ telnet metaserver.ecst.csuchico.edu 3530 |& sed -e '1,3s/^/#/' -e '$s/^/#/' > keys.dat keycomp keys.dat [replaced reference to charon -- JCH] Keycomp is nice stuff. I manually place the motd_list it produces in my server motd, but I suppose we can automate that too, if it is holding anyone back from using the metaserver. -Eleazor (of the little-used server bete.mit.edu) ------------------------------ From: trown@ecst.csuchico.edu (Nick Trown) Newsgroups: rec.games.netrek Subject: NBR Date: 10 Jul 1993 21:43:06 GMT I have put together my guzzler server source for those that are interested. This code is based on the bronco source from last year with many new improvements. A list of some of the more relevant ones are: - Short-packet support (up to pl11) - Ping stats - Clue-checking - SINL resources - SINL poping code - SINL plague code (Eric's stuff) - Features support with client version checking - SYSV support - Many more sysdef options. - Chain reaction code - Tells how a player died (with short packet support) - Automatic metaserver-RSA keycomp/motd updating. - Improved Makefiles that make it easier to keep uniform between the sub-dirs. (recursive Makefiles, includes in Makefiles). Many of the options above can be enabled or disabled by using either a sysdef or with defines. You can find the code at ftp.ecst.csuchico.edu in /pub/netrek/src. If you have any comments you can email server@ecst.csuchico.edu. Thanks! Nick ------------------------------ From: trown@ecst.csuchico.edu (Nick Trown) Newsgroups: rec.games.netrek Subject: Re: Please help me compile Date: 3 Aug 1993 19:27:50 GMT nicki@hpsmo133.rose.hp.com (Nick Ingegneri) writes: >I am attempting to compile to netrek client/server programs for a HP 9000/755. >The code appears to compile fine, and then I do the following: > > 1: newstartd (to start the server) > 2: x11netrek (to start the client) > >The client proram then establishes a connection and appears to be working >fine. I log in, pick a race to join, and then it brings up the map screen >and hangs. The following message is displayed in the client's terminal: > > 1) Got read() of 0 (err=0). Server dead > Whoops! We've been ghostbusted! > Pray for a miracle! > Waiting for connection (port 12301). This is a very common problem actually. What is going on is that the 755 is SYSV based machine whereas the server and client were written for BSD based OSs like Ultrix. Since guzzler is currently running on a 730 there is hope. I've worked in SYSV support for both. You should probably get the server code that can be found on ftp.ecst.csuchico.edu in /pub/netrek/src. It is here that the newest server code is located and it has my fixes for SYSV machines. I suggest using the guzzler.mk file found in config to compile the server up. Nick PS. If you're trying to get a server up because you're behind a firewall then trekhopd might be a way to go too. That way you guys could join the netrek community! :) (Check Tom Holub's posting of netrek FTP site for this) ------------------------------ From: trown@ecst.csuchico.edu (Nick Trown) Newsgroups: rec.games.netrek Subject: Re: Expiring? (Offer of help to server admins for RSA) Date: 19 Aug 1993 09:02:57 GMT wrote: >an9051@anon.penet.fi (Miles Teg) writes: >>My opinion of RSA is pretty low, primarily because the pipe dream >>of server gods who update their key list regularly is not occuring. I agree that there are some servers out there that don't update there key list half as often as I'd like to see. A few months ago I was getting almost a new key every other day that wanted to be added to the list. Nowadays since most people are on summer break or just getting back there hasn't been that many. Still, I urge the server admins to check the metaserver list (3530) at least once a week. >I think we have managed to insinuate automation of this into the INL >server and the Vanilla (guzzler) code now. (Bete updates automatically >every day before it goes open, for example.) The metaserver makes this >painless. The guzzler code has a program called updated that will call the metaserver, download the keys, compile them using keycomp for the server, make a new motd with a scores listing. It will also inform the server admin of any new keys added in case there was one that the admin didn't want. Painless... >All we need for this to work is for client keys to be registered with >the meta-server and server admins to install rsa_keycomp and use it. > >If your server of choice isn't doing this, send the admin a note saying >there is freely offerred code to do it (ftp.ecst.csuchico.edu is >available unless nbt says otherwise). I'd be happy to help an admin. >Part of the problem may be that many admins do not seem to be on the >trekgods mailing list and have only r.g.n to get news (take the comment >on how hard that is while you guys flame each other as read, ok?). The same goes for me. I'd be happy to help anyone that asks. As long as they know a little about programming and don't send me 20 email messages. The trekgods mailing list is also great for this. Email ctso@cups.gmu.edu if you want to be added. Yes the ftp site is for anyone and everyone :) Nick ------------------------------ From: sls@aero.org (Sam Shen) Newsgroups: rec.games.netrek Subject: Re: Genkey and client hacking I looked into genkey, re-wrote some of it and added a bunch of features. I changed the name to mkkey and it's part of the BRM distribution, or you can get a slightly newer version by asking me to mail it to you (there are trivial differences.) mkkey has several advantages over genkey: 1. It works properly with GNU mp. GNU mp is very fast and runs on just about everything. 2. It has lots of checks to make sure the key is o.k. 3. It reads old-style keys.h files and reads/writes new-style keycap files. 4. It generates client-side code that is more secure than the old keys.h method. In particular, it keeps the private key mixed up so that even if you dump the client it's still painful to reconstruct the key. -Sam ------------------------------ From: trown@ecst.csuchico.edu (Nick Trown) Newsgroups: rec.games.netrek Subject: Server 2.01 is here Hi, We have finally finished working on Server 2.01 (guzzler code). There have been many many improvements and code cleanup. I've included a change log below to show the changes in the new release. Some of the more important changes are: 1) Messages and warnings now use varargs. This helped reduce the huge number of temporary buffers and all the sprintf calls. Things such as: char buf[80]; sprintf(buf,"%s %.16s is now %2.2s (%.16s@%.32s)", ranks[me->p_stats.st_rank].name, me->p_name, me->p_mapchars, me->p_login, me->p_full_hostname); pmessage(buf,MALL | MJOIN, addrbuf, me->p_no); now become much simplier as only being: pmessage2(0, MALL | MJOIN, addrbuf, me->p_no, "%s %.16s is now %2.2s (%.16s@%.32s)", ranks[me->p_stats.st_rank].name, me->p_name, me->p_mapchars, me->p_login, me->p_full_hostname); 2) The source has been removed of all system dependent code. Everything is now handled in config/config.h. All server defines are now in there also. 3) RCD support and newer hockey.ksu.ksu.edu puck code included. Nick pl8 - 2.01pl0 : Wed Aug 18 21:54:34 PDT 1993 More fixes for robots when all players leave the game - Mark Levine. Made the Makefiles smarter. Now checks for Makefile in res-rsa since PGP doesn't come with one. Also checks to see if LIBDIR exists. - Nick Trown Fixed many many links for defs.h, data.h, data.c, and getpath.c - Nick Trown The tools are now installed in LIBDIR/tools (if you're upgrading from an older version then you should rm LIBDIR/*). - Nick Trown More Linux support of SLS 1.2 and 1.3 - Kurt Siegl. Defines are removed from the .mk files. A new file in config called config.h has all the defines and also machine dependent include file checking. - Kurt Siegl. Server messages and warnings use varargs now to reduce the amount of temporary buffers and use of sprintf. - Nick Trown Fixed small bug with CHAIN_REACTION taking away your kills when TEAM kill happens. - Nick Trown New Getentry team selection function that should be better and faster than the old one. It allows for more choice in team selection and is less rigid than the old one. - Mark Levine. Added support for the .clue-bypass. It uses the same format and the bypass file. What happened to it? - Nick Trown Added support for NTSERV in makescript. - Dave Gosselin Added new CHAIN_REACTION code from INL server. - Tedd Hadley / NBT Fixed small date problem with updated - Brian O'Neill Added !confirm to features.c. This sends a string to only a client that is older than the version specified. - Nick Trown Fixed conquer message flags. - Nick Trown Short Packets have been updated to pl14. - Hadley, Heiko, nbt Added support for 64 bit machines (alpha) - nbt, Pagnucco Got rid of hard-coded message sizes - Nick Trown Made features.c smarter - Nick Trown Added variable distress code - jmn, jn, nbt Added Max pop code for non-tmode - Nick Trown Added SB kills/hours to scores.c - Alec Habig Added pledit. - Habig, nbt Updated to new puck code (from ksu) - Kantner 2.01pl0 - 2.01pl1 : Mon Sep 27 18:19:21 PDT 1993 Ultrix fixes - Habig Makescript fixes - Habig , nbt distress.c (RCD) fixes - nbt, nelson, jmn class field added to rsa_keycomp - Hadley ------------------------------ From: fadden@uts.amdahl.com (Andy McFadden) Newsgroups: rec.games.netrek Subject: Re: Metaserver request... Date: 3 Dec 93 19:01:26 GMT In article <2dnhbf$7fk@bmerha64.bnr.ca> tomt@bmers161.bnr.ca (Thomas Taylor) writes: >What I am looking for is source code for a metaserver (I think). what I >want is something that players can call up, and it will tell them which >of our local servers is running, and how many people are playing, they >can then select which server they want to try to call. The code for MetaServerII (now running on metaserver.ecst.csuchico.edu and, for a little while longer, charon.amdahl.com) is not available for distribution. I did this so that we wouldn't end up with 100 micro- metaservers at every campus on the planet. The Netrek servers would spend more time answering metaserver calls than sending player updates. The code for port-1 (a daemon that sends the status on port 2591, assuming the standard port is 2592) should be on pittslug.sug.org. I think it's called "playerd". If you set that up on each of your servers, a simple shell script could telnet to each and get the status. ------------------------------ End of SERVER SECRETS *********************