BORGS All about borgs, aka cyborgs, aka scum :-) ---------------------------------------------------------------------- Date: Sat, 24 Nov 90 20:47:57 -0500 (EST) From: "Terence M. Chang" To: Bulletin Board Administration Subject:The robots are coming. Hi. Some of you have may already have seen non-Andrew players bringing in characters that were robots or cyborgs (i.e., autonomomous program-controlled ships or human-controlled ships with computer assisted firing.) I am in the process of configuring the server to allow 'bots on certain nights or certain hours. I don't have any 'bot code myself, perhaps some Berkeley players will be willing to ship some over here. I have seen bots that: never miss a phaser, lead torps perfectly, dodge automatically, accept commands to suicide specific players, and all other kinds of weird stuff. Let your imagination run wild. The first step is to get the client sources: one of several possible places is ~games/src/ColdStorage/netrek.tar.Z. The catch is that you need to plug in a file called reserved.c, appended to the end of this post (Yeah, I know, *gross*, but it's only 1.5K). Delete the tarred file "reserved.c.crypt". Robot hours will be announced shortly. For now, robots can join at any time. Just run your compiled client like the ~games version. Terence ------------------------------ /* reserved.c * * Kevin P. Smith 7/3/89 */ #include "copyright2.h" #include #include #include #include #include #include "packets.h" makeReservedPacket(packet) struct reserved_spacket *packet; { int i; for (i=0; i<16; i++) { packet->data[i]=random() % 256; } packet->type = SP_RESERVED; } encryptReservedPacket(spacket, cpacket, server, pno) struct reserved_spacket *spacket; struct reserved_cpacket *cpacket; char *server; int pno; { struct hostent *hp; struct in_addr address; unsigned char mixin1, mixin2, mixin3, mixin4, mixin5; int i,j,k; char buf[16]; unsigned char *s; bcopy(spacket->data, cpacket->data, 16); bcopy(spacket->data, cpacket->resp, 16); cpacket->type=CP_RESERVED; /* if ((address.s_addr = inet_addr(server)) == -1) { if ((hp = gethostbyname(server)) == NULL) { fprintf(stderr, "I don't know any %s!\n", server); exit(1); } else { address.s_addr = *(long *) hp->h_addr; } } mixin1 = address.s_net; mixin2 = pno; mixin3 = address.s_host; mixin4 = address.s_lh; mixin5 = address.s_impno; */ /* Now you've got 5 random bytes to play with (mixin[1-5]), to * help in coming up with an encryption of your data. */ /* Encryption algorithm goes here. * Take the 16 bytes in cpacket->data, and create cpacket->resp, * which you require the client to also do. If he fails, he * gets kicked out. */ } ------------------------------ Date: Mon, 26 Nov 90 12:41:57 -0500 (EST) From: "Terence M. Chang" To: Bulletin Board Administration Subject:reserved.c Whoops, I forgot to post it. Here it is. I know the concept of robots is sort of fuzzy for a lot you. It's like computer-assisted netrek basically. Robots are interesting only when they are fighting other cyborg/robot players. There will probably be only 1 robot night plus some other robot hours. Also, you may want to check out the source for Hoser and HAL/ M5/ Guardian/ Colossus. Presently they're not available anywhere convenient, but you can get the sources for everything (client and server) via anonymous ftp from scam.berkeley.edu as src/games/ipcxtrek/Netrek.tar.Z. The files of interest will be ntserv/rmove.c and maybe ntserv/robotII.c. Terence ------------------------------ Date: Thu, 4 Apr 91 15:15:43 -0500 (EST) From: Hugh Moore To: Bulletin Board Administration Subject: Re: cyborgs There are some clients that I don't mind at all, and some that I do. Of the four major clinets, these are my opionons. 1) Phaser clients. There are three versions of these. One of them pinpoints and hits the closest target when fired (This is OK in my book -- it just makes a player into a better player. It's cheap, granted, but not unduelly.). Type two automaticly fires hits any uncloaked enemy ship within a certain distance (This is a powerful client, but it takes a lot of control from the player. I don't like it because it is no longer the player who determines what is going on in the game.). The third kind is like the second, but doesn't distinguish between cloaked and uncloaked ships (I dislike this type for the same reasons as I dislike the last type. I also hate it because it is in essence making the cloaking device a useless feature. They put it there for a reason, and messing with it ruins the game.) 2) Plasma clinets. These automaticly phaser any and all enemy plasma within a certain distance (I hate these. It makes plasma, which people have to earn and then pay a LOT for, into a detriment instead of an asset. Once again, I don't like clients which in essence remove a feature from the game.) 3) Cloaker clients. These critters show cloaked ships on the short range scanners. (Obviously, I don't like these.) 4) Turn clients. These alter the speed of a ship to optimise its turn radius. ( Couldn't care less about these. I've played people using them, and frankly, I can't tell the difference except that they lose lots of ground on runner scum.) There are other clients that I have heard of but not seen. I don't know if they do or even can exist. These include clients that fire all eight torps in a burst, clients that det all incoming torps at zero damage rang, clients that can instantly orbit any planet from anywhere in the universe, clients with trocking torps, and clients that are aways carrying one army (even after they put it down). In general, I don't like clients simply because they remove the aspect of 1 to 1 person to person combat. Clients that allow seeing cloakers make genocide virtually impossible. My oppinions of clients rate them in this order: Worst -- cheater clients (like cloaker clients which give you something that even a perfect player couldn't match) Not so bad -- superhuman clients (like phaser client 2 or plasma clients which allow reactions which could be matched by a luck shot, but do it consistantly0 Not very bad at all -- player improvements (like phaser client 1 or turn client) ZZnew guy (remember, if you're using a client, it's the client having fun, not you.) ------------------------------ Date: Thu, 4 Apr 91 16:58:28 -0500 (EST) From: Craig Boas To: Bulletin Board Administration Subject: Re: cyborgs Hi All! In answer to Marc's question: ... there are players out there who have semi-automated ships which improve their fighting skills? Yep! And they are impossible to detect until you do something stupid like fire a plasma at a plasma-cyborg and get it blown up on top of you before it's even on the screen. Basically, the client program is easy to modify. I don't know much advanced C, but I was able to build a functioning "cloaker-client", which I promptly discarded after determining that it would make the game somewhat of a joke. Using a client in some cases is *cheating*. Especially on the main server since clients are not allowed most nights there. The clients are supposed to be kept out by a code that the client has to send or somesuch thing, but I know of several people who have cheater clients running on Bronco and, quite frankly, it rots. The point here is that people cheat in many games, and it's difficult to stop. The best soultion I can think of would be to periodically change the "lock" on the main server and the client in ~games/bin, but even that is not foolproof, since after all they did get the code once. On clients in general, I'd like to make my own client that alerts me to certain things which I wouldn't consider cheating. For example, One that makes a small + appear next to my ship when my shields go to zero so I know to put them down or one that displays planets more to my own taste so I can see the *number* of armies on a planet and not just an icon or lack thereof etc... These are improvements *I'd* consider fair, but I don't have the codes to get into Bronco. Balton ------------------------------ Date: Fri, 5 Apr 91 03:11:50 -0500 (EST) From: "Terence M. Chang" To: Bulletin Board Administration Subject: Sighborgs I am somewhat concerned about Hugh's post, because he expressed what appears to be a number of common misinterpretations about modified/customized clients. Without getting really technical about the server/client code (well, I will eventually), let me say this much: You can play *well* with a cyborg -- you *cannot* cheat. The reason is simple. It is server that decides how many armies your ship has, what warp you are doing, whether or not you may fire another torp, and so on. All the client does is tell the server "I'd like to phaser at (x,y)" and "I'd like to beam down", etc. Basically all it's really doing is collecting keystrokes and mouse clicks. Now, of course, a cyborg can make optimal use of the information that comes from the server. Note that a client is *not* entitled to know everything the server knows. In fact, all clients work with the same information, cyborg or not. Clearly cyborgs can do some tasks well, such as phaser plasmas. And they can repeatedly fire a phaser and keep it locked on a target. No brainers. They cannot fire torps faster than the server allows. If you see very tightly bunched torps coming from a ship, you can bet the server was momentarily overloaded/blocked and could not maintain the proper real-time spacing between torp launches. They *cannot* see cloakers perfectly. The server doesn't allow it. Notice how cloakers (both friendly and hostile) seem to drift randomly on the galactic map from their true locations? This is because the server gives *imperfect* information to the client. A cyborg may elect to draw the drifting cloaker on the local window in addition to global window. This is fine--it wanders on the local window, a lot. Plus the cloaker's true direction is not drawn, since it is not available. Well, all that aside, you wonder what the point of a cyborg is. And unfortunately the answer is rather circular: cyborgs are for fighting cyborgs. I had hoped that people would freely distribute primitive cyborgs with elementary features (e.g., auto-phaser-plasma) so we could see some interesting Darwinian evolution. [An advanced understanding of C and Unix is a prerequisite to client hacking, that is a problem.] To date this has not happened, and it may not until ... well, you read 2001, didn't you? Modified clients are allowed SatSun 10am-5pm and Tuesday nights. It is not possible for the server to distinguish between clients and non-clients, especially if the reserved.c encryption routine has been stolen/cracked. Humans aren't good at identifying all cyborgs, but in general I wouldn't worry about it. I don't see how anyone could enjoy using a cyborg against humans. Terence ------------------------------ Date: Tue, 13 Aug 91 07:52:27 -0400 (EDT) From: "Terence M. Chang" To: Bulletin Board Administration Subject: Cloaking, plasmas, informational clients On cloaking: I think the way cloaking is presently implemented fits well with the rest of game play. During Tmode it is possible to be totally "inviso" to the enemy -- you do in fact appear to go to (-100000,-100000) when you are 1/3rd of the galaxy from any enemy when uncloaked and 1/7th of the galaxy when cloaked. Also, Netrek does not differentiate between the short and long range displays -- there is really just one display shown at two different magnifications. Cloakers _could_ be drawn on the short range window, but I've tried it -- it's confusing, because the cloakers' positions update so infrequently and the error in position is so large. As for plasmas: I think they fit in the game well also. Plasmas help out a team that is concentrating on planet defense, and usually aren't beneficial at other times. Also, the winning team becomes obliged to ogg the plasma shooters. Then you can play " I'm pretending to ogg the guy with plasma but really I'm trying to soften up this planet but I won't make it so I'll just ogg him and phaser his own plasma on him ". It adds a little more depth to planet defense. On clients that display more information: I may try to add some of the simpler suggestions. In the olden days ("We used X10, and we liked it!"), I remember that the monochrome client could still boldface, italicize, and underline text, producing a display just as rich as the current color display. Underlining is a thing of days past (unless I reimplement it), and I'm not sure if the current client supports italics (finding italics fonts may be a problem). If any Xlib wizards want to look into it, I'd appreciate it. Terence ------------------------------ Newsgroups: alt.games.xtrek From: mummert+@CS.CMU.EDU (Todd Mummert) Subject: Re: Other clients. Date: Thu, 24 Oct 91 22:04:31 GMT Well, I wrote most of the pig client. However, since I did grab a couple of key items from someone else, I promised not to release source for the time being. binaries for (sun3, sun4, pmax, i386, rt) are available via anonymous ftp on auk.warp.cs.cmu.edu (128.2.242.102) in /pub/netrek. In general, these were compiled under mach, but at least the sun binaries work under 4.1.1. there is a README file in that directory but it may be out of date; i'll check on it. This client is the most stable one I have, the pig tournament team uses a client that is slightly different but not in any major areas. Mainly more configurable for different keymaps, handles cloakers slightly differently, etc. todd -- Borgeoisie Pig -- note: players w/ afs access should play from /afs/cs.cmu.edu/user/mummert/netrek ------------------------------ From: solaris@IASTATE.EDU (Roger A Wong) Newsgroups: alt.games.xtrek Subject: Re: which borg does what? Date: 9 Jan 92 14:24:40 GMT WHAT BORG DOES WHAT Just don't quote me on (or get mad at me for) any of this. All of the following information is either public, with permission from the author, or from my own experience. If I've offended anyone, please forgive. PUBLICLY FTPABLE BORGS THAT ANYONE MIGHT HAVE ================================================================= The Pig Borg Written by Todd Mummert Available via ftp from: I forgot. But binaries for almost all systems. AutoPhasers plasma and ships. AutoPressors ships in blow up range AutoTorps ships in a given proximity Automatically aims torps. Reports when an enemy picks up armies. Raises shields. Cloakers are shown on screen Cloakers on galactic map shown as R4 Pros: Simple to use and very effective. Environment variables can be changed on the fly. Cons: Completely automated. Though you can switch clients on and off, they will fire by themselves within operation parameters (which you usually don't want the client to do). And, alas, you cannot save your settings to a file (at least in the public version) Popcorn Rating: 8/10 (I'm a harsh grader) ================================================================== The Solaris Borg III Written by Roger Wong Available via ftp from: tbird.cc.iastate.edu 19 (port number) anonymous. email address as password cd /usr/solaris solborg.dec3100 (No Suns or Sparcs yet) AutoPhasers plasma AutoPhasers ships Mouse fired torps fire in bursts of two Cloakers are shown on screen Cloakers on galactic map show as ?R4 User definable linkage system. i.e. Link your phasers and torps and torp detters to the spacebar, so you hold it down, and it phasers, torps, and dets torps continiously. Macro messaging system for wptemp, etemp, oggers, and fuel low. Annoying macro messaging system. "Eat your wheaties, kid." --- (Private version only) Ships, planets, torpedoes visible on both sides of the wall. Ship rotation with the "," "." and "/" keys. --- Pros: Weapon systems can be toggled on/off. When off, they can be enabled with a keypress. A borg to use when you just want a borg as a backup, not your primary weapon, or just to annoy people. :) Cons: No torpedo aiming. Phasering parameters can not be changed. Popcorn Rating: 4/10 ====================================================================== PRIVATE BORGS (Don't ask the writers for them, they won't give it to you) ====================================================================== The Borg Written by Fil Alleva AutoPhasers plasma AutoPhasers ships Cloakers are shown on screen Cloakers show as ?R4 AutoTorp AutoPressor Raises shields Detonate enemy torpedoes Detonate self torpedoes that miss Keeps tabs on the number of armies enemies transport and pickup. Borg Escort service. ======================================================================= The AMC Info Borg Written by Alan Carroll Wrap around plotting of all objects (ships, torps, planets, etc.) Auto phaser of ships and plasmas. Display of the number of players on each team, and independent ships Army carrier detection, using indicator (below) and message to myself. My ship graphical annotation: locked, low fuel, weapons hot/overheated, engines hot/overheated, beaming up, beaming down, SB docking enabled, tractor/pressor on, refit / change war pause. Enemy ship annotation: >= 1 kill, tractor/pressor active, beam up/down active, army carrier, SB docking enabled, at peace, in orbit, targetd by autophaser, being tractored/pressor by me. Note: The SB dockok mark and kill mark are in the same place, so SB's are not marked for having kills (who cares if an SB has kills?). Ships on the galatic map are plotted in upper case for ships with kills, lower case if not. + Accelerators: . Meta-shipid for "Ship X carries" . Control-left mouse for toggling carrier status on a ship. . Shift-right for lock onto planet (_not_ a ship) . Meta-control right for message "Going for with armies" . Meta-control-shift right for lock and message . Meta-control left for message "Incoming at " . TAB - detonate all current torps and fire a new spread of 8. . control-T tractor nearest enemy ship. ================================================================== The Mercy Borg Written by Luke Hankins Autophaser ships and plasma What else, I don't know. ================================================================== The Fadden Borg (name unknown) Written by Andy McFadden auto-phaser vs plasmas auto-phaser vs nearby enemies auto-aimed torpedo bursts cloakers appear flashing on tactical map possible to get info on cloakers visual indication of ships engaging tractor/pressor beams ================================================================== ------------------------------ From: fadden@uts.amdahl.com (Andy McFadden) Newsgroups: alt.games.xtrek Subject: Auto-shield policy Date: 13 Jan 92 22:17:54 GMT I've been playing a cyborg with the following policy for auto-shields, and it seems to work pretty well. If you have a better scheme or see problems with this one, please send some e-mail. * STRATEGY: * - if we're orbiting a hostile planet, let the user decide. We may wish * to continue bombing under fire. * - if we're orbiting a friendly planet, let the user decide unless there * are incoming torps or we take damage. This allows us to repair or beam * up even though there are enemy ships nearby. * - if we're cloaked, let the user raise or lower shields at will. Don't * raise them if we get within phaser range (ideally they can't see us), * but bring them up if there are torps close by, we are near a hostile * planet, or we take damage (from a phaser shot or exploding ship). * - otherwise, raise shields when something dangerous is too close, and * lower them when the danger is gone. (as with all special features, this can be deactivated from the Options menu.) ------------------------------ Newsgroups: alt.games.xtrek From: explorer@iastate.edu (Michael L Graff) Subject: FTP site open to place all these neat borg you write. Date: Thu, 9 Jan 1992 20:59:38 GMT Now that Roger has taught everyone to write their own borgs :) we need a place to share them. I have a few meg free, and would be willing to set up a directory here on 'ol tbird.cc.iastate.edu for people to place their versions, preferably with source. To get the first one, Roger's own Solaris III, ftp to tbird.cc.iastate.edu and look in the directory "usr/solaris" for a DECstation 31/21/5000 executable, compiled under Ultrix 4.1 on a DECstation 3100. In case you didn't know, tbird is also a netrek server! Port 2592. Hope it doesn't have too much trouble being a netrek server, ftp, and my toy, too! Mail comments on the FTP site to explorer@iastate.edu, and comments on the netrek server to xyzzy@iastate.edu. Happy hacking! ------------------------------ From: paulsen@pixmap.seas.upenn.edu (Brian Paulsen ) Newsgroups: alt.games.xtrek Subject: New sunborg documentation Date: 5 Feb 92 02:52:38 GMT Ok, new version of the sunborg is out. Probably the last unless I hear some good ideas on how to change it. For those who don't know, the sunborg is available at tbird.cc.iastate.edu in /usr/solaris. You will have to change the permission settings on the file. This involves typing (on Unix) chmod 777 'filename'. How to use this client..... I. Basics o Shift-K - pops up a menu that allows you to turn each feature on/off individually. Default is for all features to be on. The last entry closes the window. All changes take affect immediately, not when the window is closed. The second-to-last entry allows the client to handle two different types of torps. The current default is to expect the torps to be similiar to those on rwd4. If you click on this item, the client will toggle between expecting vector_speed/normal torps. o TAB - will turn all features on/off...useful when you are low on fuel or want to ignore a close, perhaps cloaked, target. This function does not remember the old state of the features. Therefore, hitting TAB twice turns on all of the features. Note: The borg does not have inertial guidance initially selected. Pressing TAB does not affect inertial guidance. Note 2: The auto det torp client is only turned off by TAB. It is not turned back on by pressing TAB. II. Actions o auto-shields will come up automatically when you within phaser distance of an enemy ship, or when the client believes you will be hit by a torp. This now comes on when you are flying over a hostile planet. Does not currently come up when you are taking incidental damage from a nearby teammate getting hit/exploding. o auto-phasers hostile players are targeted when phasers will inflict a minimum amount of damage. Currently set at 25 points of damage to have auto-phasers come on. Settable by typing set autoPhaserDamage 30 or whatever value you desire o see-cloakers basically, just places the information from the galactic map on the local map. shows you ship type....ship direction shown is generally wrong. o auto-torp aiming if this is on, pressing 't' will fire at closest enemy unless the ogged enemy is nearby, in which it case it will fire at the ogged enemy. If this is off, 't' will fire a torp where your cursor is. o auto-torp firing will auto-fire torps at closest enemy closer than autoTorpDist (currently 3100). 3100 is low enough that you've probably screwed up if you're not already firing. o pressor client will try and keep the closest hostile ship at least SHIPDAMDIST (=3000) units away from you. this is to prevent you from taking damage when your opponent blows up. o army client client continually scans all planets - when number of armies change on a planet, client tries to figure out why. If the client suspects that an army is being beamed up, a message is sent to the individual review window. If an army is being beamed down, one army is taken off the number of armies we suspect that ship of carrying - Note suspected number of armies on a ship is put where wins and losses used to be in the player list. Enough people have add questions about this that I feel I should explain the algorithm that I use. As mentioned before, the client scans all planets on every update. If a planet has fewer armies than the previous update, the client assumes beaming is occurring. If a player is near the planet that has kills and owns the planet, then we believe that he is beaming up armies. If the player is unfriendly, and the planet has less than 5 armies, and the player is believed to have armies, then the client believes that the player is beaming down armies. NOW - what isn't caught by the client. Beaming to and from SB's is not caught. The client can not tell how many armies an SB has, so it is very difficult to catch this type of beaming. If we do not know the location of a player (because he is too far away from any teammate) then we don't know if he is orbiting the planet, so we can't tell if he is beaming up. Finally, if a player beams up from a planet that we have no info on, then we can't find out if he is beaming up. o plasma client really unfair client that will preferentially phaser all plasmas as soon as it can. o ogg client most borgs have the auto-aimed fire aiming at the nearest player. this does not work too well if you want to ogg a player. By pressing '.' then '5' with the cursor being over the player you wish to ogg when you press '5', that player will be selected for an ogg. This means that if this player is in oggPlayerDist, the auto-weapons will go for him rather than the nearest enemy. Also, rather than pressor this opponenet away, the client will tractor this opponent whenever he is in oggTractorDist range. This should make for more effective ogging. Neat new feature - torps that miss are detonated so that more firing can begin. Also, if you press '.' '5' on the opponent that you are currently ogging, you will no longer ogg that player. Furthermore, the borg will think you are ogging until the enemy dies. o Inertial guidance client useful for ib.sei.cmu.edu - it remembers where your ship is when cloaked. This should allow for very secretive planet takeovers. However, be warned that the accuracy of the inertial guidance is not perfect. o auto det torps client Will det enemy torps when they reach autoDetDist. Useful for taking over planets. Runs up the Wtemp, though, so be careful. III. Miscellaneous o fine tuning your client Many of the parameters controlling the client are adjustable. By sending a message to 'C', you will be talking to the client parser. Basically, the command to get you started is C--> help The format of the show commands are typically: C--> show variable-name The format of the set commands are: C--> set variable-name value IV. My additions 1) Client is automatically set for Update Galactic Map as frequently. 2) Number of armies on a planet is shown next to the planet. AGRI planets are shown in white rather than the team color. 3) If you pull up 'P' for planet listing, the client remembers each planet's status. You will still be able to find out which planets are repair, fuel, and agri even if the planet is taken over. 4) There is now a whole slew of messages that can be sent with two quick keystrokes. To do this, press '.' to enable the fast message system. Also, all messages are sent solely to one's own team. The next keystroke and mouse position defines the message. Note: These keystrokes (with the exception of the above '.') can not be keymapped. Sorry. KeyStroke Mouse Position Message '+' enemy ship enemy ship'++' '0' enemy ship enemy ship 'has' #armies 'armies!' '1' 'does anybody read team messages?' '2' 'yes' '3' 'thanks' '4' any SB SHIP 'is a SB' Note: 1-4 are pretty well useless '5' enemy ship sends nothing, but picks this player for the auto-ogg '6' enemy ship 'Ogg ' ENEMY SHIP '7' 'We need to BOMB more' '8' enemy planet 'Bomb' PLANET '- it has' > 4 armies #armies enemy planet 'Take' PLANET '- it has' < 5 armies #armies ind. planet PLANET 'is independent' '9' enemy planet 'ESCORT needed to' PLANET you have armies 'by' YOU 'with' #armies enemy planet YOU 'will escort to' PLANET you don't have armies ' - who will take?' send all comments, suggestions, and problems to paulsen@eniac.seas.upenn.edu V. Changes from previous releases. Shield comes up over hostile planets. Phasers inflict a minimum amount of damage. Default updates left at 5. .xtrekrc file can be read for borg defaults. My .xtrekrc file is included for help... AutoPhaser: on AutoTorpFire: on AutoTorpAim: on AutoShield: on AutoPressor: on PhaserPlasma: on ShowCloakers: on AutoDetTorps: off AutoOgg: on InertialGuidance: off VectorTorpSpeed: on ShowBeamInfo: on PhaserDamage: 25 AutoTorpRange: 3100 OggPlayerDistance: 10000 OggTractorDistance: 4800 AutoDetDistance: 2500 FuelReserve: 1500 NOTE: The above lines describe what the borg is initially set at. Therefore, if you provide nothing in your .xtrekrc file, the borg will have the above defaults. please send any comments and suggestions to paulsen@eniac.seas.upenn.edu ------------------------------ From: paulsen@pixmap.seas.upenn.edu (Brian Paulsen ) Newsgroups: alt.games.xtrek Subject: more sunborg documentation Date: 5 Feb 92 03:04:59 GMT I forgot to mention that there is also a fuel reserve. If your fuel is below this reserve, the auto-phasers won't fire. paulsen@eniac.seas.upenn.edu ------------------------------ From: paulsen@stipple.seas.upenn.edu (Brian Paulsen ) Newsgroups: alt.games.xtrek Subject: another new sunborg is out Date: 10 Feb 92 08:34:36 GMT Rather than reproduce the documentation, I will simply describe the changes. First, I recommend reading the docs, because they provide more detail than what I will describe here. I have noticed that the borg seemed sluggish. With the great help of Todd Mummert, I have vastly improved the borg's speed. This might or might not be somewhat noticable, depending on your lag. Auto-aimed torpedos now take into account orbiting enemies. Old torps use to fire into never-never land for orbiting enemies. No longer. Phasers use torp explosions to fire at cloakers. New planet bitmaps for showing unknown planets after the borg has seen them touched. Borg knows server names, so that little typing need be done to use a server. For example: to get onto harvard, type sunborg -h harvard servers recognized: rwd4, bronco, ib, harvard, duke, bezier, calvin, auk Windows are titled after the server you are on. Real useful when you have multiple wait queues. Shift-A brings up an interface for easily modifying the client's variables. The borders reflect current alert status. Again, the docs have more detail. ------------------------------ From: diachun@acsu.buffalo.edu (Justin D Diachun) Newsgroups: alt.games.xtrek Subject: Helix borg version 'c' release Date: 11 Feb 92 06:51:56 GMT The following is the new readme file for helixborg version 'c'. There are a large number of new features, so if you liked version 'a', check out version 'c' right away! Mainly, there is now a good autoshield, vector torps, army beaming messages, improved 'smart' phaser lock, and a user-friendly parameter setting interface. Note: version 'b' was not a public release, so that's why you never saw it. This file and the borg are available on ftp from netrek.iastate.edu; sun3 and sun4/sparc binaries available NOW, dec3100 soon (hopefully!). ==================== helixborg.README ==================== My goal in writing this client has several directions. Mostly, I wrote it because I enjoyed it! I kept thinking of additional extras to throw on, and I wanted to see what they would look like. Clearly, the pig client is the most popular at this time. The vast majority of the look and feel of this client is based on the pig client. I hope the author does not take offense; I want people who have already become familiar with the pig client to be able to use helix borg easily. In addition, I believe the pig client has been set up in a very striaghtforward and reasonable manner. In addition, I have a strong feeling that the pig client and helix borg underwent very similar steps of development. For example, the boldfont selection seems to be the same. This is not meant as a copy of the pig client--I tried almost every font available! But this seems to be the only one that is both clearly readable and would erase itself easily without leaving graphics smears. I hope people will appreciate the extra features that I have installed. I know I like them! I am more than willing to discuss any of these and try to optimize them to please the general public as much as possible. I am still in the process of writing and modifying, so new features will continue to add up and be installed, based on your input. At this point I believe any feature available on the pig client is also operating on helix borg. Plus there are lots of new ones too! I can't see why anyone would choose the pig client over helix borg at this point. I would like to hear any arguments. This help file and the helix borg are available from ftp on netrek.iastate.edu as pub/netrek/bin/borgs/helixborg.* Features: Client options window All the toggles can be made from the options window, similar to the Pig client. The settable options are listed inside [] on the right in yellow. By clicking on one of these, the left button decreases the parameter by -5, the middle increases by +1 and the right increases it by +5. Most of these values are listed in phaser damage that you expect to do to a target, or phaser damage you expect the enemy to do to you. The values can be set specifically by sending a message to the client (shift-C) and entering the parameter listed between the brackets followed by the new value to reset it to. They can all be set in your .xtrekrc file. SHIFT-K to map/unmap. Beast bitmaps Bitmaps for the beef/beast client are included. These are fairly striaghtforward--the planets always show owner and resources both. The resources listed down the left side of the planets from top to bottom indicate AGRI, FUEL, and REPAIR in that order. This may take a small amount of getting used to, but it is a nice improvement. Armies for each planet are listed to the right on both local and galactic maps. For races that you are peaceful with, number of armies are not displayed. Also, if a planet has exactly 4 armies, no count is given since this is a generally uninteresting number. Bitmaps made by leonard@cs.umd.edu. Please give me feedback on these bitmaps. If public demand is high, I am willing to change them or offer an alternate set as a map cycle. Show army beaming When an enemy player beams up armies from an IDENTIFIED planet with a known number of armies (and he is shown on your galactic map), a message is sent to the individual review window from the client. The number of ship wins/losses on the player list can be switched to show number of armies carried and turns on the beaming messages. Army carrying ships appear in boldface on the galactic map. ctrl-m toggle. Note that even when the option is toggled off or borg switch is OFF, the number of armies is still updated and can be displayed next to the ship on the local map as explained in the option below. The source code for this feature was adapted from the sunborg, by paulsen@pixmap.seas.upenn.edu. Note: army count may be inaccurate, especially if beamed to/from a starbase. Show kills/armies Right under the ship number on the local map, the number of kills the ship holds (rounded to nearest integer) can be displayed. For your own ship, the number of kills appears in the color of your ship's alert status. A third toggle is implemented which shows the number of armies that a ship is believed to be carrying, or nothing if it is zero. ctrl-k 3-way toggle (none/kills/armies). Target selection Sending the client a message CLIENT->[kill g] will make all auto aimed weapons target at player 'g'. This is very useful if you want to og someone or pick them out of a crowd. It is especially nice when ogging a starbase. ctrl-y toggle on/off. SHIFT-Y to select target with mouse. Note: this is only in effect if the targeted player is close to you. Weapons act normally until then. OGSCUM This is an auto og routine that seeks out the nearest target and homes in on it. As of now, it knows nothing about self-defense. It generally cloaks, charges, tractors, and tries to dish out some heavy damage. If target selection is off, it goes after the closest enemy ship. If target selection is on, it ignores all other ships if within range of the target. This could be abused horribly, but it can be fun for a few minutes. ctrl-z toggle. Manual activation/smart defenses Auto phaser of plasma is mapped to the detonate key (it does both). I don't like to waste fuel on a plasma that won't hit me, and I think it looks really stupid to phaser wildly at a poorly aimed plasma. Ship will uncloak first if plasma targeted. Also, torp detonate will raise shields first, and not function if total hull+shield remaining is less than [det 50] setting, the detonation threshold. If this is set at zero, shield raise and phaser plasma are inactived. Message Beep When a message is received on the personal or team board, a bell sounds. ctrl-b toggle. Auto phaser Firing range initiated by the client is set by sending CLIENT->[phaser 30] for 30 point phaser hits. This is the amount of damage that you will do (determined by ship type) before auto phasers initiate. ctrl-a toggle. Auto phaser cloakers If you don't like to automatically initiate phaser fire on cloaked ships, it can be turned on/off. Only operates if auto phaser is turned on (of course!). Phaser hit followups from manual first hits work on cloaked ships even if this is turned off, as long as autophaser is on. ctrl-c toggle. Auto phaser plasmas Setting [plasma 1] will phaser plasmas up to 1 point damage phaser range, and [minplas 70] will give up if they are closer than 60 point range (explosion backlash range). ctrl-p toggle. Fuel reserve Use [fuel 1400] to keep a fuel reserve of that amont to prevent auto phaser from wasting all your fuel. Keyboard phasers ignore this. Will discontinue auto phaser hit follow-ups when fuel is low. Smart phaser If auto phaser is ON, then phasers will continue to fire at the ship as long as you keep getting a hit and it remains within [minphaser 10] point phaser range, and fuel reserve is not passed. Phasers from keyboard or autophasers fire at closest/targeted ship. Followup fire will also continue on cloaked ships even if auto phaser cloakers is OFF. If you do not like phaser fire to be INITIATED by the client, just set [phaser 100] or higher and then it will only keep firing after you make the first hit manually. Smart torps Torps fired from the keyboard are aimed at the nearest player if he is within your torp range. To account for netlag, set the value [lag 2] to indicate how many updates you are falling behind, and the torp lead will be increased. Torps also take into account for your own tractor/pressor beam strength by ship type, and will aim accordingly. Smart torp no longer leads cloakers (it used to) since you have no idea which direction they are flying anyhow. Vector torps can be activated by a ctrl-v toggle. Most of this routine came from sunborg. Auto torp Adjustable range by sending [torp 65] for initiating auto torp fire if the nearest enemy is within 65 point phaser range. You are probably dust at this point already, but useful against battleships. ctrl-t toggle. Auto pressor When a ship enters the range of [press 60], for 60 point phaser damage on you from his ship, pressors come on. They stay on until the ship is outside at least [maxpress 50] phaser damage distance away. ctrl-r toggle. Auto shield I adapted Andy McFadden's article for autoshields as my policy. Shields are under user control while in orbit. They raise when enemy closes to [shield 7] point phaser range for HIS weapons (i.e.: sooner if he is a BB, later if he is a SC), when torps are within [torphit 55] points of his phaser range, when nearing a hostile planet, or when you take damage (explosions, etc). If you are cloaked, it ignores enemy phaser range. Show cloakers Cloakers appear as r4 on the galactic map (lowercase) in their team color. Ship number appears in center, with new bitmaps for friendly or enemy cloakers on local map. ctrl-l toggle. Galaxy class and new independent/Iggy bitmaps All modifications are from starting with the galaxy-client source. Galaxy class ships are compatible. Someone posted a new set of bitmaps for independent ships a while back. I installed them. Nifty! Respond to the "Pig Call" If you send 5 spaces to ALL, the client responds with "Helix borg version c, 2/10/92". In addition, the validation packet responds with "Cyborg" if anyone wants to use that to invalidate the client on their server. OFF switch Use the TAB key to toggle all combat borg features off temporarily. Toggle will preserve the current settings. Information features remain on. Extra goodies Phasers or torps fired during repair mode briefly turn off repairs to send the weapon request, and re-activate repair mode. Handy during orbit! Cruise speed key '^' goes speed int(maxspeed/2) for shiptype. Shields turn color to indicate their strength remaining: 100-50% white, 50-20% yellow, 20-0% red. If you carry any armies, the number shows up in red. Distress calls gives fuel too. Better default fonts. Let me know if they don't work out for you... default setting in .xtrekrc All options that can be set through the client options window can be given as defaults in the .xtrekrc file. On/off defaults as well as numerical values can be set. In addition, two other features can be turned on initially. The number of updates/second that you prefer as a default is set as [updates]. Setting updates to frequent for the galactic map is set using [frequentgmap]. ------------------------------ From: diachun@acsu.buffalo.edu (Justin D Diachun) Newsgroups: alt.games.xtrek Subject: Helixborg dec binary fixed, release 'd' Date: 3 Mar 92 09:51:27 GMT Minor new features: Message Highlighting If you get a distress call from a ship, you see a highlight flashing around it on the galactic map for a few seconds. If a planet is mentioned at the start of a message, the planet is highlighted by a circle that expands and contracts from the source. Mouse phaser lock When turned on, this will fire phasers from the mouse at the nearest ship to the mouse, taking into account the [lag] variable. Generally not suggested for people having bad lag. Show kills/armies/speed Third toggle added to show ship speed instead. ------------------------------ Date: Wed, 12 Feb 92 17:39:35 EST From: Leonard Dickens To: jch@cs.cmu.edu Subject: beef.README General Beef is an information borg of the pure white kind. I have not and will not implement autoweapons of any kind for this borg. I am interested in any info features that people add however, other than show_cloakers and army_tracking. All suggestions and especially criticisms are welcome; mail to: leonard@cs.umd.edu or catch me on while I am testing on rwd4, swcs9, or ib. Features Beef's differences from the normal blessed binary are as follows: o All new planet bitmaps Planets are displayed vaguely like this: ___ __/ \ |A| ^ 7 / /*\ \ |F|/***\ | \ |/ \| / |R| / \___/ Earth Agri, fuel and repair are indicated by fixed boxes on the left of a planet; the planet's number of armies is shown in white at the upper or lower right. A planet's number of armies is always shown on the local window; in the upper right if >= 4, or the lower right if <= 3. (Independent planets have no owner shown, and are thus extremely obvious.) A planet's number of armies is only shown on the map window if the number is not equal to four, and the planet is yours or an enemy's. The owner insignia is always displayed. o message beep A beep is generated every time a message comes to you or your team. o planet highlighting If a word is found in any message to you or your team that is the beginning of any planet name (and at least 3 characters long), that planet will be highlighted by a short animated sequence on the map window. The first character in the string is always treated as captitalized. (This allows you to type "ori+++" instead of "Ori+++".) o player highlighting If the first word of a message to you or your team is either "Distress" or "Help", the sending player will be highlighted by a short animated sequence on the map window. o X11 interface improvements Green/Yellow/Red alert work. The patches found in jch's client-hints are installed, presumably making all the X windows act more nicely. Windows get appropriate labels. The wait window now is laid out more to my taste, and uses the big font for more readability. o server nicknames You can now use server nicknames to call netrek; they are specified in your .xtrekrc like this: # server nicknames: Bezier: 128.32.150.109 Bronco: 128.2.210.65 The wait window and netrek window get labelled with the server name you are using, or nickname if that is given. o internal mods for speed Rewrote status line reporting in redraw.c. Replaced some blanking calls in redraw.c by calls to a new function in x11window.c, W_OverlayBitmap. Made the warning function only erase as much of the line as needed, as it overwrites the rest. o internal mods for correctness Gcc doesn't seem to want to compile beef (or the vanilla client.) Part of the problem was a function in defaults.c which I removed, called strcmpi. It works exactly like strcasecmp except that it destructively modifies the strings. Seems that gcc is smart enough to put initialized strings in the text portion of the program, which caused this function to dump core. Beef compiled with gcc still has weird crashes that take place when you get killed, that I have not yet tracked down. (On the sun4 anyway) Do not compile beef with gcc yet. Upcoming stuff: o Client menu 'K' for setting the client's parameters Right now there is no way to toggle any of beef's features on and off, as there ought to be. Hack the code if you don't like them. o Quick messaging feature Allow a large number of "standard" messages to be sent with only a keypress or two. Also, I intend to allow variables in the messages, requiring mouse specification of planets and people. Other I am distributing a small c program, "bm_array", with the beef bitmaps. It is used to concatenate sequences of identically sized bitmap files into what I call bitmap array (.bma) files. The netrek client source likes some of its bitmaps (for example, the torpedo explosion sequence) to come in this form so that they can be interned in a for loop. ------------------------------ Newsgroups: alt.games.xtrek From: mummert+@AUK.WARP.CS.CMU.EDU (Todd Mummert) Subject: - comments on borgs (esp. authors) Date: Tue, 04 Feb 92 20:27:37 GMT I'm the author of the Pig Borg and with the recent influx of new borgs I'd like to make some comments. Most of these comments are a result of watching some of the recent games involving lots of different clients. I think there are certain things client (borg or otherwise) authors should be very careful about: 1) Do not set updates very high. I did this initially with the Pig Borg and it was a mistake. Not necessarily here at CMU because our net can pretty well handle it, but it was a mistake to release it to multiple sites where I did not fully recognize the saturation of the local networks. I would suggest that all clients be released with updates set to 5. The better players will change this if the situation warrants. The problem that currently exists is that with the borgs defaulting to high update rates, the neophyte players do not know how to reduce the updates, so the server remains swamped. Also, for the same reason do not allow it to be set in the .xtrekrc file. Experienced players can adjust it as necessary, but clueless players would just end up either setting it high and forgetting about it or grabbing a .xtrekrc file from someone else and living blissfully unaware of it. 2) Do not have functions that send messages to ANY board automatically. This includes the cute taunts, the army pickup messages, etc. It becomes highly annoying very quickly and if everyone does it it puts an unnecessary load on the server. I have been given the argument, "Oh, it's ok...only my borg does it." Making any borg an exception is unreasonable and I urge everyone to refrain from doing so. 3) Do not send your personal information messages through the server. Hack dmessage/smessage to print it out directly to whichever window you want. Do not place it in a message to yourself as this will end up going to the server first. Basically, just do not use the sendMessage() call to print out information in your various windows. 4) If you are working on coordinating multiple clients, do not send these control messages through the server. It's unfair to penalize the other players for your increased communication needs. The correct way to handle this is to open up your own connections between the clients and communicate over the new connection. Not only do you not load the server, you will also get shorter latency times between your clients. Ok...so a short recap... 1 - Set default updates to 5. Do NOT allow this to be adjusted from the .xtrekrc file. 2 - Do NOT send unnecessary messages through the server. just my opinions, of course... Borgeoisie Pig ------------------------------ From: davidt@ccwf.cc.utexas.edu (David Teo) Newsgroups: alt.games.xtrek Subject: GrandFather Borg Version 1.0 Date: 1 Apr 92 04:44:51 GMT Hi There! The most automated borg in public domain is available from cs.utexas.edu [ maybe needmore.cs.utexas.edu?? -- jch ] /public/sun4/bin/netrek/gfborg. GrandFather Borg Version 1.0 is available for the sun4 system only. Features include : Auto Shields Auto Phasers Auto Torps Auto Tractor Auto Pressor Auto Phaser Plasma Auto Exit Planet Auto Repair Auto Bomb/Beamdown See ships carrying armies See cloakers See ships with >= 1 kills Auto Detonate Enemy Torps (wont recommend this feature to be on though) Monitor Enemy Beaming See armies on planets Vector Torps Version 2.0 will be coming out soon. I'm testing it right now. It will include AutoBeamup Auto Plasmas Shoot through Border Auto Pilot (Robot Mode) in case you want to lean back and watch the fun. Robot has only a ratio of about 1.7 though Move through Border See through Border and many many more. Parameters can be controlled while playing or set via your .xtrekrc file. An example of the xtrekrc file is also provided. Robot features will include hostile mode (seeking out enemies), berserk mode (a self-sacrificing fighting style to kill skillful enemies) (dont worry it can login as guest so your ratio wont be affected), go near certain ships to attack a specific enemy or to protect a friend. So on and so forth. It has everthing in the Pig borg and more! A help file is provided with it. ------------------------------ Newsgroups: rec.games.netrek From: mummert+@AUK.WARP.CS.CMU.EDU (Todd Mummert) Subject: PigBorg 3.0 now available Date: Wed, 03 Jun 92 03:35:07 GMT Version 3.0 of the PigBorg is now available. This version has all the options of the regular Pig team borg, except that they don't communicate with each other over a seperate channel. Of course, UDP V1.0 is included at no extra charge. Additionally, I've grabbed Randy's autopilot dodge code and thrown it in for humor value alone. There's also an auto-lockon mode that will continue to lock onto a player even after dodging torps. I'm releasing this for two reasons: 1) to try to balance the field out w/ regard to UDP borgs and 2) to try to get a larger field of testers for the autopilot features. Basically, I'd like feedback as to improvements or suggestions for the dodge code and whatever else you'd like to see. The PigBorg is available via anonymous ftp from: auk.warp.cs.cmu.edu (128.2.242.102) in netrek/PigBorg.* the manual is in netrek/PigBorg.manual Feel free to place this in any other archives. I currently have binaries for pmax_mach, sun4_mach, sun4_sunos, but will compile for whatever assuming I have access to a machine running whatever. Borgeoisie Pig p.s. -- as the manual states, you must have the name of the blessed beast or its by-products in your name for the client to work. ------------------------------ From: news@organpipe.uug.arizona.edu Newsgroups: rec.games.netrek,alt.games.xtrek Subject: How to make a borg Date: 23 Jun 92 01:27:57 GMT I've been cooresponding with ALOT of people about borgs and robots. Many are interested in the construction of one, but don't know how to start out so they ask me minor questions on how to do certain things. To be quite honest, I really enjoy working on borgs/robots, talking to people about borgs/robots, playing borgtrek, AND playing netrek, so I don't mind at all. However, things might go faster, and the same things might not end up being said over and over same things to different people, if there was a guide, or an ftp-able explanation. Here it is, a guide at the level of someone who has just learned C but is not familiar with netrek. If you have already worked on the client profusely or are a professional programmer, this will hit you square in the ankles. If you run an ftp site, I'd appreciate if you included this file. Note that it DOES NOT give away source for a borg, only leads a person through a few, easy examples. "Guide for Modifying Clients" aka "How to Make a Borg or Robot" The following is a thorough instructional/tutorial guide for modifying clients. My motivation for creating this was simply that in the process of playing netrek, a number of people have started cooresponding with me about writing borgs and robots. In order to answer their questions and the questions of others, I've decided to write this file. Clearly, a patch could easily be distributed that would generate a borg or robot. However, I have no intention of doing so, instead this document leads you through the creation of a borg with a couple simple features, and a feature that would be more at home in a robot than a borg, but which is widely used by most borgs. From the examples given, the reader should be able to expand to a large number of additional features and behaviours. Disclaimer: There are clearly people much more suited to write this file. Many have been modifying clients longer than I have, and a few who were directly involved with the creation of netrek itself. If this file serves as a decent guide, it has served it's purpose. -------------------------------------------------------------- Generally, there are three kinds of borg features. 1) interface (visible tractor, cloaker....) 2) key action (torp firing, message macros) 3) automatic (phaser_plasma) To start the reader off, one example from each of these areas will be shown. In writing borgs and robots, you almost always modifying a client of some kind, so you are using someone else's code to start off with. Thus you should NEVER insist that you wrote the whole thing yourself, and if you want to claim ownership, phrase the ownership statement as ownership over the modifications not the client source itself. Before anything can be modified, the original code must be in hand. The standard bronco client code is good, but doesn't allow for galaxy class ships. The galaxy class code is probably what you want then, because it behaves exactly like bronco but also allows you to play the galaxy class ships. Further, be sure the client you have is UDP-ized. UDP is a new communication system similiar to TCP, but is faster at the expense of reliability. In addition to the client code, you should also obtain the bronco server code. This is because the bronco server contains a great deal of very useful code that can be used to easily add new features to the borg. Also, in some cases, you want to know exactly what the server is doing, like the rules for planet beamup or tractoring ships for example, so you want to look at the code that does this (and sometimes include it into your borg). It is not necessary to actually get the server running, but right now, before making any modifications at all, you should get the client running and make sure it works. There are other documents describing the compiling of the client so I won't bother doing that here. OK, now you should be ready to start modifying your functioning code. After each modification, you should immediately recompile and test the new modification to be sure it works. This makes debugging easy because you recall precisely what has been changed and might have caused certain bugs. Here are the borg features that I'm going to describe to you. Each of these features is very easy to add. Show Cloaker Differentiated planet/player lock Plasma Phasering This last feature, plasma phasering, serves as an example of a robot feature. It is done without the user doing anything at all. Many more complex behaviours can arise, including the construction of a robot that automatically bombs and takes planets. In fact, at this time, a team of robots called SFOP has genocided a team of humans (although they still can't approach the best human teams). Note the difference between borg and robot is generally accepted to be that a borg is a modified client in which the client does operations which normally would be left up to a human, while a robot is a program which plays netrek by itself without human interaction. SHOW CLOAKER Normally the client doesn't draw cloakers on the local map but does show them on the galactic map. The galactic map coordinates are less accurate than local map coordinates AND cloakers have a random error applied to them, but it is very easy to show the approximate position of the cloaker on the local map. In redraw.c, search for the word PFCLOAK. This is an obvious thing to do, because redraw.c handles all the drawing of information on your screen, and somehow it must know not to draw a player when they are cloaked. PFCLOAK stands for Player Flag CLOAK and thus indicates when a player is cloaked. PFCLOAK appears in multiple areas, but one of them should look basically like this: if (j->p_flags & PFCLOAK && (j->p_cloakphase == (CLOAK_PHASES-1))) { if (myPlayer(j)) { W_WriteBitmap(dx - (cloak_width/2), dy - (cloak_height/2), cloakicon, myColor); clearzone[0][clearcount] = dx - (shield_width/2); clearzone[1][clearcount] = dy - (shield_height/2); clearzone[2][clearcount] = shield_width; clearzone[3][clearcount] = shield_height; clearcount++; } continue; } In human terms, this code says: Is this player cloaked and not coming out of cloak yet IF SO: Is this player me? IF SO: I should know where I am, so draw me IF NOT: Do nothing In order to make it draw everyone, whether or not they are cloaked, all you have to do is remove the line which says 'Is this player me?'. What this involves is just commenting out the if-then, so the code now would look like: if (j->p_flags & PFCLOAK && (j->p_cloakphase == (CLOAK_PHASES-1))) { /* if (myPlayer(j)) { */ W_WriteBitmap(dx - (cloak_width/2), dy - (cloak_height/2), cloakicon, myColor); clearzone[0][clearcount] = dx - (shield_width/2); clearzone[1][clearcount] = dy - (shield_height/2); clearzone[2][clearcount] = shield_width; clearzone[3][clearcount] = shield_height; clearcount++; /* } */ continue; } That's it, try recompiling the client and see if you can see cloakers. Now, the above is a VERY simple modification, there is a great deal more that can be done along these lines. These modifications fall under the class of 'interface'. DIFFERENTIATED PLANET/PLAYER LOCK Often you want to orbit a planet, in doing so, lock onto it from a great distance and approach it. Then suddenly find yourself sniff the rear end of a battle ship instead of orbitting. Conversely, you might want to dock at a base and find that instead you locked onto a planet near the base. Things get particularly confusing when many players are near a planet. It is possible to seperate the lock so that one key, say 'l' locks onto planets, while another, say ';' locks onto players. First let's take a look at the code that does the normal locking. In input.c, search for the word 'lock'. Again, this makes since input.c controls the keyboard and mouse interactions of the user. Inside input.c is a very long switch statement which says if it was this key then do such-and-such, if it was this other key the do so-and-so. We want to add another key action option in to this switch. The section of the switch which controls locking looks similiar to this: case 'l': /* l = lock onto */ target = gettarget(data->Window, data->x, data->y, TARG_PLAYER|TARG_PLANET); if (target->o_type == PLAYERTYPE) { sendPlaylockReq(target->o_num); } else { /* It's a planet */ sendPlanlockReq(target->o_num); } break; Again, in human terms this says: In the case that the key pressed was 'l': Figure out what was being pointed at from either planets or players If it was a player, ask the server to lock us onto the player otherwise it was a planet, so ask the server to lock us onto the planet Instead, we want to have it lock onto only one type of object. So our new instructions should look something like this (in human terms): In the case that the key pressed was 'l': Figure out what was being pointed at among the planets Ask the server to lock us onto the planet In the case that the key pressed was ';': Figure out what was being pointed at among the players Ask the server to lock us onto the player Now I expect that you should be able to figure out how to do this yourself quite easily. Try doing it on your own, if you are familiar with C it should be no problem. Here is one possible way of doing this. case 'l': /* l = lock onto planet */ target = gettarget(data->Window, data->x, data->y, TARG_PLANET); sendPlanlockReq(target->o_num); break; case ';': /* l = lock onto player */ target = gettarget(data->Window, data->x, data->y, TARG_PLAYER); sendPlaylockReq(target->o_num); break; Once again, that is it, try compiling the code and test out the new feature. This is a key action modification, now you should be able to figure out easily how to add other such things into the code. Again, there are a large number of other things that can be done. PHASER PLASMA One of the more powerful things that borgs do is autofiring of phasers and torps. I'm NOT going to show you how to do that, since doing so would basically constitute showing you exactly how to make a decent borg. I'd rather you figure it out for yourself. However, another powerful feature is the automatic phasering of enemy plasma that enters the borg's phaser range. This modification is considerably more difficult than the above 2 but is also easy, since the robots built into the server will do it automatically. You just need to figure out how to transfer the code. Let's look at the code first. It is in rmove.c of the server. rmove.c is a source file for the server robot program and is an invaluable resource when you are starting to write a robot. Search for the word 'phaser_plasmas' in rmove.c. This is a function which the robot calls to check if any enemy plasmas are within range, and destroys them immediately if they are. All you have to do is have your borg call this function. To keep things neat, you should group the code that your borg runs each update in one area. So that I don't have to explain how to modify Makefiles, just stick a new subroutine, called borgmove(), in one of the existing client files, say in input.c. Initially, this subroutine is only phasering plasmas, so the call to this subroutine should look something like: borgmove() { phaser_plasmas(); } You also need to include that phaser_plasmas subroutine somewhere in the client (copying it over from the server code). Just stick it onto the end of input.c also. Now you need to call borgmove() somewhere also. There are a variety of places to call it from, some better than others. Sticking it directly into the input loop is good enough (although someone may correct me on this). The main input loop I'm refering to is in input.c and the head of it looks like this: while (1) { while (!W_EventsPending()) { In human terms this means: Keep repeatedly doing the following forever Keep repeatedly doing the following while there is not a window event This loop just keeps going while the client is running. The inner loop related to window events is run (basically) whenever an update comes in, so anything that you want run every update should go here. Thus you just make the call as the first line of the loop: while (1) { while (!W_EventsPending()) { borgmove(); if (W_Socket() != -1) { Try compiling, you will undoubtedly get a few errors. I'm going to talk about a few common errors you'll encounter in modifying the client now, before explaining how to fix the current problem. One problem is not including the right libraries/includes at the top of the source file, or including them in the wrong order. Generally, when you are copying code between source files, make sure that the libraries/includes are similiar, and if you have problems, then just try to add libraries/includes that were in the original file but not the new source file. Another, and probably the largest, problem is the information differences between server and client. The server knows everything, the client knows ONLY what it has to know. Many precautions have been imposed in netrek to make sure that the client did NOT recieve any information that you wouldn't expect it should know (such as the precise position and velocity of a cloaked ship). Get used to finding bugs that have to do with this lack of information. Finally, the last error I want to discuss, like all programming, sometimes copying a subroutine by itself isn't enough because of global variables. In this case, in fact, I anticipate that you will get an error because the client doesn't have the variable 'phrange', which was generated by the server robot. An easy way to fix that here is to simply define this variable inside the phaser_plasmas() subroutine and set it equal to a constant (this is clearly not the best way). Try compiling again. Once again you should get an error. The subroutine phaser() is not in the client, but was in the server. The equivalent call in the client is sendPhaserReq(course). Changing this call should fix the problem. This reminds me of one last error that you will probably make several times before you get a good idea of just where the client and server interact. In rmove.c search for the word 'p_desdir'. Somewhere, you should find a chunk of code that looks like: me->p_desspeed = dogfast; return; } if (random() % 2) { me->p_desdir = NORMALIZE(enemy_buf->e_course - 64); This is how the server robot is changing it's speed and direction. The server robot has direct access to shared memory, it could change it's own hull points if it wanted to. In fact, the HunterKiller robot DOES change it's ship type all by itself, the server has nothing to do with this. A client, whether blessed, borg, or robot, DOES NOT have access to the shared memory, and can not change such strategic elements of it's characteristics. In the above code, the robot changes it desired speed and direction all for itself. This is not the normal way of manueverying. In another location, in fact, the robot changes its speed directly, bypassing the server: me->p_speed = me->p_ship.s_maxspeed; If you included this line into a borg or robot in your own client, the server would simply ignore you. (Read LOGIC BUG LOGIC BUG!!!) These errors are, of course, really, really, really difficult to locate when you start out, but you get used to spotting them easily later on. Now that you have autophaser plasma working (hopefully), you should be able to easily generalize on how to add other robot features, such as locking onto a planet and bombing it, etc... So, that's pretty much all, good luck coming up with new ideas for borg features and robot behaviours. If you would like additional information/discussion, feel free to contact me at nelson@soliton.physics.arizona.edu If you are having problems getting something working, particularly the phaser_plasmas described above PLEASE contact me. I'd like to know if I missed something in any of the above descriptions. Also I'd like to warn you. Many borg authors have found that playing borg IS NOT as fun as playing normal clients. When you have auto-fire, det, dodge, shield, and the like, then you start to lose some of the true excitement of dog fighting itself. Hope to compete against some of your robots in the near future. HAVE FUN!! - Jeff ------------------------------ Newsgroups: rec.games.netrek Subject: Borg/Bot/Client/server authors mailing list announce From: mcn@cwru.edu (Michael C. Neuman) Date: 5 Nov 1992 03:25:50 GMT Due to popular demand, I've created a mailing list for borg/bot/client/server authors. Subscribe yourself by sending mail to: trekwriter-request@b62103.student.cwru.edu ... Mail to the list by trekwriter@b62103.student.cwru.edu. (Sorry 'bout the hostname :( ) I'm hoping to create a forum for discussing bot algorithms, and sharing ideas for server hacks. (Hopefully the analogue (and possible predecessor) to rec.games.netrek.programmer) ------------------------------ From: davidt@cs.utexas.edu (David Eng-Yeow Teo) Newsgroups: rec.games.netrek Subject: Latest GrandFather Borg Date: 6 Nov 92 07:51:55 GMT Hi! Latest GrandFather Borg just sent to grind.isca.uiowa.edu should be in the /unix/netrek/binaries directory, as for when it will appear there, pester milutz@icaen.uiowa.edu. He's the one in charge. Not all bugs have been fixed though, sorry no time. However, there are definitely a couple of improvements over the older version like a modified version of jch's windowing, ocf client interface, Bronco client interface, and some borg code fixes etc. Try it and see. I'll try to fix it in the future but at the mean time, you may pester nicknac@wam.umd.edu. Yes, pester him, :) he has the entire borg code and he can compile different versions of the borg for you. For instance, if you have a color monitor and you would like the planet bitmaps to be like the original bitmaps and not like the beef bitmaps, tell him, he can compile one for you and etc. etc. However, don't pester me because I'm not going to be here :). Happy netreking! See ya! P.S.: Above all, the new borg is smaller and faster. -- David Teo ------------------------------ End of BORGS ************