Col Hogan

http://www.thearmory.cc/index.php?name=PNphpBB2&file=viewforum&f=3

http://www.thearmory.cc/index.php?name=PNphpBB2&file=viewtopic&t=757&postdays=0&postorder=asc&start=30

Just curious, if okay to answer, any reason for order on list like most recent or largest amount ?

JAWHOL !! Hair Commadant. Having TBT at top for while, as well as playernames, has been getting boring, same maps, same routine, etc. Sort of a been there done that thing I guess. Think I'll do less heavy armor flag rushing and maybe experiment with different weapons and tactics, hopefully in different maps too. I welcome you Bumbo as additional Thunder Bayite. Remember like most other regular players here know with me, I get "driver's tunnel" vision when in FA, not becasue I in sewer a lot, but I usually get so involved moving watching listening for enemy I simply miss a lot of screen text. And in case you end up wondering why your name is not clickable to see how you've been doing, you'll need 2 hrs non-stop to start it, then maintain minimum of 2 hrs in each 14 day period as it drops the 14 day old stats every morning at 6:20 when it updates last days stats. Your rank will get inline with your skill points from flags, boxs, trucks, etc when you become clickable.

me me me :roll:

I, as many of you know, luv it. But I don't sleep with it I use standard sight with it. Did accuracy test in empty map on wall target picture of Saddam in Basrah. At what appeared to be about 40 feet. When I placed the sight arrow on the face in single shot, it hit dead on each time. Burst made a triangle each time hitting forehead and lower cheeks. Auto sprayed on the wall above the head between few inches and 12 inches. Putting arrow on upper chest got this mode to land on face.The very fast rof causes the bullets to angle up. Farther will mean higher, closer will land lower. Whereas other games like bfv's m60 make gun and sight move. forcinf you to keep moving mouse up to try to hold it down.I rarely have any luck at distance with single or burst mode. Prefer to charge/dodging left/right to get close enough for easy kill. or sneak around with stealth knowing most surprise run-ins will get face full of lead before i do :wink: in conclusion i've found it only reliable at close range with occaisional med range kills which i considered lucky shots and/or he was low on health.it would be interesting to be with others with all different guns, in experiment only, to learn and note how much health lost from single shot bullets to see if different gun bullets casue more or less damage, with all having same armor. then try different armor strength on all to see differance.show i just watched compared ak47 with m16. ak had terrible inaccuracy and recoil while the m16 was very accurate with much less recoil. partly from using smaller bullets and charges and partly from lighter gun wieght. so ak strategy like us famas people was to sneak or surprise closeup giving it's faster rate of fire and larger bullets chance to overwhelm opponet.

Red Alert 2 or RA2 Yuri's Revenge anyone ? "See mee....feeeeel meeee", my wrath that is, there as "cam1959".

lol :roll: i think there are other England things named with brow-raising north american words or pronounciations :wink: anyone know anymore ? My Scotch history has some too, aaauck, con't remember any laddy !!

:wink: 1st most play time you ^_^ imagine of this were football, you "tight end/rusher"

1-Anyone that's played this, confirm it is same CS style that has no reins, making you wait for all to die or lose map, to get back in ? This is why although I have previous CS, I rarely use it. on the other "hand", maybe that would be good for those "long" trips to the outhouse ;-) Also, does it still have : 2-cash earned from winning maps needed to buy gear and weapons ? 3- team voice chat ? 4- rather small maps ? Any other noteworthy details you can point out about it ?

I wonder if, steam allowing downloading of full software is reducing need for stores, truckers, salespeople to sell it? If this gets used more and more in future from all internet sites, could it reduce need for stores and jobs that go with them ? Also, could the internet, or their servers be so bogged down that internet user quality would suffer as we've seen plenty of through steam? I realize it is a big cash supporter which they would claim is needed to update their game system cost and keep increasing it's user support ability. However, they had no problems with their won servers before like they now have with steam using much more internet bandwidth of all servers and users. a solution is to either pay more for internet plyable games or pay to play on net like a number of game servers now. If I were in government, i would put to vote whether only demos and updates/upgrades to full software should be offered thru net. the $20 or so each person may save downloading full software thru net, multiplied by many thousands of people, equals that many stores/jobs/job-earnings lost maybe in future. how might that effect the stock market and unemployment rate ? besides, most of you know internet hacks/attacks/viruses/etc ... mean we sometimes end up reformatting/reinstalling everything ... so better to have cds for faster restoration :wink: as result of these many considerations, i enCOUARGE Y'ALL to let these corporations know these considerations. YES to UPDATES/PATCHES/UPGRADES/DEMO TRIALS ... NO TO FULL SOFTWARE DOWNLOADS :roll:

maybe lose the "." between 2 and 5, confuding it as to folder name or file ? it's not too often i can say dumkolf to you hair commadant B)

maybe lose the "." between 2 and 5, confuding it as to folder name or file ?

will steam show both fa and fa25 on game list ?otherwise all i think of is having to rename folders so 25 has original fa folder name to be one used by steam.

yavol !! dankashien :wink: changing maps and order often i think good idea to keep an old game as interesting as possible :wink: i mean, i don't mean i often think, i mean, often changing good idea :wink: Salute :wink:

looks like maybe some people are over-reacting from possibly not entirely accurate interpretations of what is intended for TAC by it's owners and cost payers.whoever owns and pays to run pcs/net accounts is free to decide what they like to do with it. well, not "free", since it all costs a lot. respect them for doing what they have for us in past. those that complain about having this game or not that game maybe should put their money where their mouth is :wink: operators are saying "as it is" ... low use game pointless supporting unless lots willing to pay to play :wink: by being able to get game and help server costs for it. in the end it's up to owners. they see server use and query with posts how many willing to play this or that atleast by game purchase to figure out if it will get much use on server.so don't think you have to quit, continue supporting games running here by playing them and helping in forums, not "flaming" in forums. "flame" or vent, if you feel the need, with private messages :wink:and remember, we are all not perfect, can get frustrated from time to time, take only so much wining and complaining, no matter WHO we are. so take it easy on the complaing side as i think there's been a lot. i know ... nothink :wink: sorry about new thread on same but other got locked and it seems the subject or fire needed some water on it :roll:

did you and doc send all those steam crash mdm files to steam like you suggested we all do ? maybe we shouls set day/time to all email these attachments at once ? maybe not, that not nice. i dunno yet if steam has email to send to.

does anyone know for sure of we need to let the steam files build up in fa folder ? there seems to be new one made each time it updates. currently few dozen in there, of susbstantial size. latest one was yesterdays date and is called "Steam__100418__2004_9_23T6_43_42C3851870.mdmp".

god grief, Charlie Brown, you're out there doing whatever pleases you ? :shock: Everyone turn their scanners on :shock: Hope you do your best to enjoy it :wink:

Well, yes, people tire of the same thing after a while. Getting new maps helps. Having team voice chat helps in 2 ways, 1 is humor and laughter from hearing team mates, 2 by adding team help recon of enemy whereabouts, adding to sense of team play and interest longevity. It's also more of an adreneline rush at times because of the faster pace in smaller maps. I will not likely buy another that does not have voice. As I predicted months ago, seems I was right eh ? :wink: See quote below from my old post on this. BFV made me laugh at 1st from it's music and vehicles. That wore off fast. Anyway, salute to y'all, whatever you decide.

tanks. i noticed couple missing so added them. what does the cl_forward "400" control ?

the thread is locked. i have couple questions on that topic ...1-does it work to call up console as i did, to edit those settings, before joining a server ?2-are those settings saved for future fa startups ?

ok, thanks, PUNISHER ... the reason I've been exploring the setup of both pcs here for me and Tigerhawk is ... I've been trying to figure out if there may be problem with high-speed cable at our end ... or, software setup ... or anyhing else ... all been checked out to be good ... THE PROBLEM FOR LAST FEW WEEKS HAS BEEN ... when you play as PUNISHER or JOBU, as well as another player named PARABOLA ... we get major lag/fps drop when either of you come near ... no problem with any other palyers or in other servers ... we.ve heard and seen on screen as well, other players complaining of same lag when you around ... stuff like 2 fps and gun clicking but not shooting at you ... so we're wondering if you have any idea, like "modifications" / "tweaks" / etc ... ? not accusing you of anything ... just wondering if you or anyone has any idea why this happening ? it's frustrated Tigerhawk to point of not playing with her usual name if you there ... i've explored all possibilities that may cause it at this end and found nothing to explain or improve it . has anyone else noticed anythiong similar with gameplay at TA when these 3 names are there ? we not pointing fingers :wink: just trying to figure out why it only happens to us and others when you 2 are there.

The following is a copy of file sent to me by TA FA player. If admins think it bad idea to mess with these console commands to change FA net use "cvars", then I apoligize and understand if you take this post out. It has some surprising/interesting info. I wonder if some already using these mods may casue others that are not, net performance probs...I've put this off too long Over 4000 words and its done (or rather ive got bored of adding to it, youll have to do without the troubleshooting section). It would be nice if you could move this to teh support forum o?nce it becomes inactive. This is my long-awaited netcode guide for Half-Life in general and Firearms in particular. It is not specifically designed for a single connection type, nor will I give you any specific values, since the best value depends o?n almost every aspect of your system and connection. I will, however, often refer to modem or broadband since these are so wildly different despite their many types. ISDN users will just have to consider themselves as being between the two I also a section of tweaks for server admins. And no, I wont tell you how to produce fake lag (its easy to do though). And anyone else who has a cached LAN, you're buggered. Just accept it, theres not much you can do except act like you have a modem. Remember that Half-Life is a single player game, and was designed as such. Anything that seems a stupid way for a multiplayer game to work probably is, but is there because it is a good way for a single player game to work. So this time, please no they would never do it that way comments. Many of you will wish to skip the next few paragraphs, which explain how the game works, and go straight to the cvars later o?n. However, reading the explanation will make it easier to understand what you are doing, and will help to find the best values. And you will have to follow the cvars in order, as most of the tweaks I give wont help unless the previous o?nes have been done. In a single player game, there is no point in the game working out what is happening between frames, since the gamer will o?nly be affected by what they can see and hear. Half-Life therefore proceed in game frame. In single player these are simply the same as the graphical frames (as in fps - frames per second). Whilst the graphics card renders the next frame, the processor calculates what is happening in the game (damage levels, movement, AI etc.), and the next frame does not start until both tasks have been completed. In a multiplayer game, this works slightly differently depending o?n whether a listen or dedicated server is being used (dedicated servers are indicated by a small server icon next to them in the server browser, others are listen servers). For a listen server, the network frames (the frames in which the network game proceeds) are the same as the hosts game frames, and therefore the same as their graphical frames. For a dedicated server (and all good servers are dedicated) the rendering task is stupidly easy, as a dedicated server merely displays the console, which can be rendered extremely quickly as there are no 3d calculations to be processed. Therefore the servers frame rate will depend only o?n how fast it can process the game information (calculating movement etc.). Dedicated servers typically run at 80 fps or higher, and during lulls in the fighting often hit the HL framerate limit of 100fps. They would run at 100fps all the time except for having to handle all the requests for data and client updates. Try setting up your own server, o?nce a few players join then your framerate will drop markedly. In the current version of Half-Life, Valve claim that network and graphical framerates are completely separate, allowing modem users to run at 100fps without degrading their network performance. In a way this is true, so long as graphical framerates are far (at least 3 times) higher than network framerates. However, a new network frame still cannot be started until the concurrent graphical frame is finished. This means a graphical framerate which is close to the network framerate can cause irregular network frames. Because of the way in which both the internet and Half-Life work, network problems such as high latency and packet loss are minimised by having a regular stream of updates. This is because of synchronising with the servers framerate, setting up virtual circuits o?n the PoPs, and modem time-switching algorithms, amongst others. Thus irregular network frames lead to the things we all hate, the several phenomenon which are categorised as lag. I feel I had better describe what these are before I tell you how to minimise them. Ping - Don't ask me what it stands for, I can't remember. The P is for packet though. This is the amount of time (in milliseconds, or thousandths or a second) between a packet being sent by your computer to the server and the reply (the ping) being received. This is the o?ne which is most dependant o?n your connection type, most modems will take around 150ms to even get to their ISP, so pings rarely get below 200. An ADSL user will probably o?nly have 10ms or so to their ISP, so they start hitting the fundamental speed limits of their part of the internet, and these are the players who are most affected by server location (if you can call the difference between 30 and 80ms an effect). Packet Loss - This is probably the most important and most tweakable effect, but o?ne which is often ignored in favour of ping. A lost packet is o?ne which at some stage of its journey is discarded, either because it is too old (the most usual o?ne) or because bandwidth limitations prevent it being forwarded. Those annoying Connection Problems? Those are when your packet loss hits 100% (ie nothing is getting through) for a few seconds at a time, or even permanently (which is why you drop after a while if your not tweaked correctly when these awful problems occur). Choke - This is the average time (in milliseconds) between a packet being generated o?n your computer and it being sent to the server. It is o?ne of the major goals during tweaking to get this to 0, or at least as close as possible. Broadband Slowdown - High pingers DO NOT cause lag. How that stupid myth got around I don't know, but it's complete nonsense. In fact, as you probably now guessed, broadband connections slow servers. Broadbanders ask for many updates a second, each of high accuracy (packet size), whilst sending large numbers of updates themselves, again each of large packet size. All that bandwidth gets used up (the server bandwidth used by a single broadband connection could support five to ten modemers) and all the packets being sent place a drain o?n the servers processor and RAM usage. The most unfair part of this is that its actually the modemers who feel the attendant drop in performance the most, in a way paying for the sins of the broadbanders. Maybe that's why the myth grew, whenever there's a slow server, any modemers will have a high ping, so broadbanders just assume that is the cause of the slowdown, not its affect. Not o?nly is it vastly unfair to kick modemers when a server begins to slow down, it also will probably make no noticeable difference. It is also worth bearing in mind that all of these are affected by the netcode of the mod being played, for example CS and to a lesser degree DoD are built to get the players pings as low as possible, without even thinking about packet loss or choke. This is all well and good for those with broadband and good graphics cards, but the teams obviously don't give two shits about anyone with a sub-standard graphics card or a modem. Thankfully, Firearms is built with a good mix of these, with such things as client side accuracy immensely helping reduce network traffic and therefore helping those with restricted bandwidth (ie, modemers). How do you find out what these values are for you? Well, Half-Life has a wonderful little tool called the netgraph. You turn it o?n by typing net_graph 1 in the console. Values 1-5 are valid, each showing slightly different things, whilst 0 turns it off. I use 3 personally, but find the one which you use the most. The netgraph can cause a strain o?n graphical fps, but I find it minimal. only those with significantly higher graphical fps than network fps should see a big drop. If so, you can decrease its size or turn it off altogether o?nce you have tweaked your netcode. The following is an explanation of net_graph 1: <see above for the pic> 1. FPS Counter - Your current frame rate. 2. Network Latency - This is your current network latency. (ping) 3. Your downstream bandwidth use. 4. Your upstream bandwidth use. 5. This is an animated graph displaying your ever-changing ping. The higher your ping, the thicker this graph gets. This also displays your lost packets in red, and mismatched entities in blue. 6. Your current server update (incoming) rate. 7. Your current client update (outgoing) rate. A CVar is a client variable (or a server variable), a value governing some operation of the engine which can be changed by the client (or server administrator). For example con_color can be used to enter an RGB value for the colour of the text in the console. I am going to examine each relevant cvar, explain its use, and give guidelines o?n its best settings. I will inevitably miss some of them (there are hundreds, although most don't really affect the network performance). In each case, x is a number, and they should be entered in the console (although they can also be entered in the command line). Netgraph CVars net_graph x - as noted above, enabled the netgraph. 0 is off, whilst 1-5 display different combinations of information. 0 is default. I like 3. net_graphpos x - determines the position of the netgraph o?n the screen. 1 is bottom right, 2 bottom centre and 3 bottom left. 1 is default. I happy with 1, but some set it to 2 and then move the compass to the top of the screen. net_graphwidth x - the width of the graph in pixels. o?ne pixel is used in the graph part for each packet sent. 192 is default. Remember to keep it large enough for the text to be readable. Net_graphheight x - the height of the graph in pixels. 64 is default. Again, keep it large enough to be readable. Ever wondered why the ping displayed o?n your netgraph is usually less than the latency displayed o?n the scoreboard? Well, the netgraphs ping is purely the network ping time. The latency in the scoreboard is more representative of the time obstacles against the player, as it includes the time each packet takes to be rendered and displayed on the clients computer. They are both useful, but in different ways. FPS Related CVars fps_max x - Sets the maximum graphical fps. Any integer between 1 and 100 is valid, whilst 72 is the default. Half-Life will attempt to divide each second evenly into this many slices. If the rendering process ends before the slice, then it will begin rendering the next, but it will never go more than one frame ahead, to conserve memory usage and stick to the framerate. If the frame isn't rendered before the slice ends, then the next slice is allocated to that same frame. No-one ever believes me, but this is the single most important variable for adjusting the netcode. Since everything in Half-Life is linked to frames, and all frames depend o?n the graphical frames, this is extremely important. The advice I see all the time is to set this to 100 (the maximum value), so that as many frames as possible are rendered meaning the minimum time between a packet being received and it being rendered. This is completely and utterly WRONG. As noted earlier, netcode revolves around predictability, and regularity is the most important thing. It is better to have a regular fps of 20 than o?ne which jumps between 20 and 30. In fact, often setting a lower fps_max can raise the average framerate, because the renderings are fitting nicely into the time slices, which eliminates the inevitable wasted time when a frame requires just over one slice to render. In fact a value which is close but not quite right is worse than o?ne wildly off, since each slice is bigger, wasting half a slice is more harmful. You need to gradually decrease this value until you find a point at which your fps is almost constant at the limit. There will be areas of some maps or large firefights in which it may drop, but it needs to be constant in normal play. If it isn't, drop it. It may start to look bad as you get closer, but when you have the correct value it will look better than you would've thought, since the frames will be regular and therefore easy for the brain to interpolate to a moving image. This is why TV looks better than a game running at an average of 24fps, since TV is always regular. As detailed below, correctly adjusting this single setting can reduce ping, packet loss and choke all in o?ne. Still don't believe me? Then stop reading this guide, the rest of it is pointless if you haven't done this step. If you end up with a framerate which is too low (ie under 20) then you should consider dropping detail levels to improve rendering speed, some tweaks for which are included at the end of this guide. fps_modem x - don't be mislead by the name, this is equally valid for all connection types. Sets the maximum number of graphical frames per second for an internet game. This or fps_max is used, whichever is lower. Any number between 1 and 100, 100 is default. This is o?nly of any use for those who play both o?n LANs and the internet, since they will run at fps_max during their LAN game, and at this in their internet games. If you didn't think fps could affect network performance, then why would there be different cvars for different network types? I bet some people still don't believe me. It is probably worth reducing detail levels and getting a higher fps during LAN games, to take advantage of the extra bandwidth. If your running over 50fps anyway its not worth it though. fps_lan x - sets the maximum number of graphical frames per second for a LAN game. This or fps_max is used, whichever is lower. Any number between 1 and 100, 100 is the default. This is irrelevant for almost any HL mod, since it o?nly matters if the mod is being played in single player (where fps_max will be used), LAN (fps_lan) and internet (fps_modem) play. I know of no such mod. The o?nly other situation I can think of this being used is if the same machine is sometimes used for running a dedicated server, and at other times playing o?n both a LAN and the internet. In this case, the fps_lan and fps_modem values would set the values when playing, whilst fps_max would be set at 100 to allow the dedicated server to run as quickly as possible. Again, rather unlikely. Idiotic Lag-Compensation CVars I say idiotic, because I fail to understand why anyone would want to change them, but when lag comp first came out everyone o?n broadband wanted to know them so some people must somewhere. cl_lc x - 1 or 0, 1 being default. 1 tells Half-Life to use the lag compensation (assuming the mod and server support it), whilst 0 turns it of. Lag compensation is the system whereby you hit what you were aiming at when you fired, instead of having to fire ahead of the target. Why you would want it off is beyond me, unless you have a ping of less than 10. Maybe o?n a fast LAN, where it would reduced required bandwidth, but since LANs have tons of bandwidth to spare anyway there's really no point. Leave it o?n. cl_lw x - 1 or 0, 1 being default. 1 tells Half-Life to use client side accuracy and recoil. If turned off, when you click fire you wont see the gun fire for a pause equal to your ping time, because it will wait for the server to tell it how much recoil there was and where the bullet went. This may make a bit of sense in mods which have server side accuracy and recoil (CS being the most obvious and heinous one), but since Firearms uses client side prediction for these anyway, and the server lines up with what the clients tell it rather than the other way around, there's no point and it actually makes the game harder, since you can't adjust for the recoil. It makes no difference to bandwidth usage, since 1 sends it to the server, whilst 0 sends the same data the other way. Leave it o?n. cl_lb x - 1 or 0, 1 being default (0 used to be, and is listed in some guides). 1 tells Half-Life to place blood sprites if the client thinks you've hit your target, whilst 0 will wait for confirmation from the server. This can look weird, and o?nly serves to indicate if you really did score a hit with highly inaccurate guns in server based accuracy and recoil mods, like CS. In Firearms its pointless. Leave it o?n. Direct Netcode CVars These cvars directly affect the network packets, so can make a large difference to performance. Setting them wrongly can make the game unplayable, or even lead to constant connection problems once you join a server. Make sure you make a note of your previous values before changing them (to find this, type the cvar without a number after it. Half-Life will list the current value). cl_updaterate x - Any integer value between 1 and 100. 20 is default. This is the number of updates the client wants to receive from the server each second. Barring something going wrong with the server (eg its fps dropping right down due to a large amount of fighting, or too many broadbanders being connected) the server will indeed send this many. The client doesn't actually send this many requests, just when you join the server (or change the value) it sends the server a packet saying please send me this many updates a second. The server will attempt to send these. The best value is equal to fps_max, but don't go over about 30 (even 25 is pushing it). If your fps_max is higher than this, then choose a value which is a simple multiple of it. Eg. if fps_max is 42 then use 21. The game o?nly really begins to look jerky around 13, so don't be afraid to try values down to about 15. This sort of value will only be noticeable when things move very quickly ingame, eg grenades from the m79, gp25 or m203. Since it's only telling you what's already happened o?n the server, there's no need to have a really high value, higher values o?nly place unnecessary strains o­n the server, leading to broadband slowdown. Oh and set this to 50 for LAN games. cl_cmdrate x - Any integer between 1 and 100. 30 is default. Basically the opposite of cl_updaterate, this sets the number of outgoing packets sent each second. There is absolutely NO reason to set this any higher than fps_max, since it will just be sending the same data twice during some frames. Since outgoing bandwidth varies less than incoming bandwidth, you can generally get away with values up to about 40 (modems up to 30). Set this to the same as fps_max, or a simple divisor (eg. half of it) if your fps_max is higher than these limits. cl_rate x or just rate x Any integer from 0 to 99999. Default is set by which connection u chose o?n install. This is that amount of data in bytes allowed to be sent every second (total of up and down stream). Basically there is a trade-off here between bandwidth and smoothness. The higher this is, the more data gets send each second, and the better the client can keep track of what is happening o?n the server. However, at the same time it takes up more bandwidth, both o?n the client and the server. As a client you will want to set this as high as you can o­n your connection, for optimum smoothness. Setting this too high will result in package loss, as there physically will not be enough bandwidth to send some of the packets. Try a bit higher than the values below and then drop it until your packet loss disappears (or reaches a minimum, it may be the server). When changing this setting, it is important to realise that it makes a difference to connection reliability, so you should try each setting for 5-10 minutes before deciding whether to drop it again. These are approximate values for the rate, although since this is the most variable setting of all your connection could be wildly different. 56k modem or 64k ISDN 2500-3000 128k ISDN 4000-5000 cable modem 6000-8000 xDSL or T1 7000-10000 LAN 10000 cl_resend x Any integer between 0 and 16. 6 is default. This sets the maximum number of times to resend any lost packets. If you have followed the above tweaks u should really get much pl, but setting this to 1 will reduce pl without affecting performance and flush too much. cl_timeout x Any integer between 0 and 1000. 30 is default. Sets the number of seconds after which the connection is given up for dead if no packets have been received. Often it is recoverable, especially if you can see the in and out rates fluctuating. Setting this to 90 works for me. Download CVars cl_allowupload x - 0 or 1, 1 default. When set to 1 this will upload any custom spray-paint you may be using. Since this causes hardly any lag, o?nly for the first 20-30secs, and since it lets other players see your spray-paint, you should leave it o?n. cl_allowdownload x 0 or 1, 1 is default. When set to 1, HL will download any sounds or maps form the server needed for the next round. For sounds this is best left o?n, since they probably rent available in a pack, and if they are by the time you've found them u would have downloaded them already. However, you should NEVER download a map this way! The map wont be zipped, and the HL connection is slower than an ftp, so you are probably trebling the time it would take you to download the map anyway. Take a look in the mapping forum here, there's a map releases thread that has links to all the custom maps I've ever needed. cl_download_ingame x 0 or 1, 1 is default. When set to 1, this will allow HL to download other players spray-paints during the game. For eh same reason as cl_allowupload, you should leave this o?n. However, the images downloaded are stored in a file called custom.hpk in your firearms folder, and I recommend deleting this periodically (every two weeks is about right) since it can get quite big and take up a large chunk of your RAM and loading time. HL will create a new o?ne as necessary anyway. For Server Admins These are tweaks a server admin can use to optimize the networks performance whilst playing o?n their server. I'm not absolutely sure about any of these, since I haven't had a server to test them o?n. sv_maxrate x Any integer from 0 to 99999. 99999 is default. Sets the maximum rate for any o?ne client. This multiplied by the max players should be about two thirds of your total bandwidth (as its not 100% efficient and u want to leave some over for spray downloads and stuff). However I often see it higher than the max bandwidth, which is stupid because everyone starts having their rate automatically reduced. This not o?nly messes up carefully set up netcodes, but it also means the modemers suffer at the expensive of broadbanders and causes broadband slowdown. I would actually like to see a server which sets this to 3000 so everyone gets the same performance, no matter their connection type, but I don't think it will happen. sv_minrate x - Same as sv_maxrate, but sets the minimum rate instead of the maximum one. a bit pointless, people should be allowed to set their rate as low as they like. Set to 0 sv_dlmax x Any integer from 0 to 99999. 99999 is default. Sets the maximum volume of downloads to send to any client in kB. MAKE SURE YOU SET THIS CORRECTLY. The absolute best value is 500. This is large enough for the client to get any sounds, but smaller than almost all maps. This mean the clients will not be able to DL maps off your server, which is horribly inefficient and really lags the server badly, especially if they are o?n broadband. Well thats all i can be bothered to do, its possible ill edit in a troubleshooting section and some more admin stuff. Sorry it took so long people

G wiz, golly G, G pers, thanks :wink: