Nätcode till Counter-Strike 1.6

Inaktiv
Nätcode till Counter-Strike 1.6

Tjenare idag ska vi prata om nätkoden i cs1.6. Alltså den delen i spelet som hanterar signalerna till och från servern. Det de flesta gör och säger att det ska vara gäller oftast bara optimalt i lansammanhang på en bostad server som kör 100 uppdateringar i sekunden. För att detta ska bli så lättförståligt som möjligt behöver vi klargöra lite saker.
Detta kan ses som en guide i hur man optimerar server och klient inställningar i cs1.6. Jag delar dessutom upp den i några delar. Om du tror du kan grunderna och terminologin som kommer senare i guiden kan du skippa del ett och hoppa direkt på del 2.

1 Grunderna : förklaring av ord samt termer

Server: Det spelet folk ansluter till är servern i sammanhanget.
Se även Listenserver och Dedikeradserver.

Listenserver: När någon startar ett multiplayerspel genom sin egen klient. Alltså den han själv sitter å spelar på kallas det listenserver. Detta är inget bra och skall undvikas Då Grafikdelen i spelet ofta sätter käppar i hjulet på själva serverdelen. Med vissa settings går det få dugligt men riktigt bra blir det aldrig.
Se även Server och Dedikeradserver.

Dedikeradserver: Ett program som kör cs utan grafik och låter folk ansluta till den för att spela ihop. Finns i 2 olika versioner. Smidigaste är att ta ner det genom steam annars finns hlds som man bara kan installera. Generellt sett så är bästa platformen att köra en server på ett linux system då dessa klarar av att hålla servern mer jämn och klarar köra på klenare system med bättre csserverprestanda. Verkar dock som om amx å dylika plugins kan få onödig cpu belastning i linux. Detta beror kanske på dålig kodning då amx faktiskt egentligen ska vara plattformsoberoende.
Se även Listenserver och Server.

Klient: Alla program som har någon form av server uppsättning har också en klient del. Klienten i cs1.6 är den du använder när du spelar. Du ansluter alltså din klient till en server för att ta del av spelet.

Netsettings: Samlings term där alla olika settings man kan göra som har med nätkoden att göra hamnar under.

Nätkod: Den delen i spel som hanterar förhandling, leverans och hämtning av uppdateringar som berättar vad som händer. Om du tänker dig ett fia med knuff där alla spelare slår sina slag samtidigt. Sedan lämnas resultat in till "Servern" som sedan räknar ut vad som sker för att sedan skicka ut resultatet till alla spelare. Då alla inte slog exakt samtidigt (pingskillnad) finns det oftast en del i multiplayer-servrar som är till för att vara smart och räkna med skillnaden i tid på de olika slagen så att allt ska funka som om det vore samtidigt. När så alla gubbar flyttat (uppdaterats) gör alla sina spelare sina drag ingen för att sedan uppdateras och forsätta på detta sätt.
Det är i grunden och lite förenklat hur det går till. Eftersom det är rent omöjligt att göra ett rent realtid spel så byggar man upp det så här och kör det mycket snabbt istället. Detta går enligt principen film gör. Alltså att om man presenterar hjärnan med en bildsekvens på 24 eller fler bilder i sekunden där varje bild följs av en bild som är lite uppdaterad så uppfattar hjärnan det som flytande. Så när uppdateringarna sker tillräckligt ofta upplevs det som om allt flyter.

Rate: Detta är klient kommando för att sätta hur mycket bandbredd som klienten får göra sig till god av. 1000 i rate motsvarar ca 1Kbyte. Med andra ord ska 10000 räcka för de flesta fall men 20000 är bättre. 20000 är dessutom hårdkodad i hlmotorn så mer kan du inte få. Blanda inte ihop det med source som har 30000 som max.
se även choke loss

Choke: Choke är en term använd i nätkoden som indikerar en flaskhals i systemet. Alltså när trafiken som vill gå fram eller tillbaka mellan servern och klienten inte kan pga av fel rates, sämre internet eller något sånt. Trista i cs1.6 är att spelet inte skiljjer på choke till eller från servern vilket gör att man inte vet i vilken ände man chokar. I 9 av 10 fall är det dock på vägen från server till klienten som flaskhalsen sitter då de paketen är större och har lättare att fastna så att säga.

paket: I nätverk som internet eller lan används ett sätt att skicka information som består i att man sätter ihop ett paket med en adresslapp. Dessa packet finns massor olika varianter av. De kan dessutom flaggas på olika sätt för att sedan hanteras på olika sätt på vägen mot sitt mål. Flaggorna funkar som ett aktas märke på vilket vanligt postpaket som helst, 4 av 5 postanställda ignorerar det. Vad som kan sägas är att cs som de flesta pingkänsliga spel kör med udp som ska tillåta att packeten tillbringar så lite tid som möjligt i routrars minnen. Ska inte snesegla mer om nätverk utan låter det räcka med detta svammel.

ex_interp: Då inget egentligen sker i realtid utan bara väldigt snabba runder är det viktigt att man får en stadig ström av uppdateringar ifrån servern. Då förlorade eller försenade paket lätt leder till lagg. Då kommer din egen klient till din undsättning genom att köra en liten bit kod som räknar ut var folk var på väg och vart de troligtvis är. Kommer förklaras utförligare nedan.

cl_cmdrate: Hur många uppdateringar i sekunden din klient skall försöka leverera till servern.

cl_updaterate: Hur många uppdateringar i sekunden din klient skall beställa från servern.
se även sv_maxupdaterate

sv_maxrate: Hur mycket bandbredd servern skall nyttja som mest för att skicka ut uppdateringar till varje klient. Man kan räkna 1000 som en Kbyte. 20000 är även här hårdkodat i halflife motorn som max värde. Formel för en bergänsad lina kan se ut som följer. 128kbyte(1Mbit alltså) / 10kbyte (per klient) = 12 spelare
Denna formel funkar på paperet men uppload limits och massa saker spelar in se nedan om configurering av servrar.

sv_maxupdaterate: Hur många uppdateringar i sekunden servern skickar som mest till varje klient. Detta värde är det som gäller även om klientens cl_updaterate stå högre. Default 30 vilket ger knappt någon marginal för instabil trafik eller förlorade packet innan konstiga saker börjar ske.

sv_minupdaterate: hur många gånger en klient skall uppdateras som minst i sekunden. Att sätta detta värde högt kan drastiskt påverka vissas ping. Default har jag för mig är 10 vilket är väldigt lite.

sys_ticrate: Antal frames servern skall försöka kalkylera i sekunden. För varje frame servern kalkylerar kan klienterna uppdateras. Default 100 dock sällan en default server går i 100fps.

fps: Frames per seconds. Bilder i sekunden. Detta är hur många bilder i sekunden din klient räknar fram. För en server så är det hur många gånger i sekunden den gör en full uträkning på vad som sker i spelet.

hitbox: HL motorn som så många andra spel använder sig av hitboxar för att registrera träffar spelare gör på andra spelare. Vissa spel som Q3 har en hitbox andra som cs har flera som reprensenterar olika kropsdelar. Dessa är i spelet osynliga för klienterna.

sv_unlag: 1 eller 0 för på eller av. Detta sätter ifall servern skall utföra beräkningar för att motverka pingskillnader.
Se även sv_maxunlag

sv_maxunlag: Default 0.5 Detta säger till servern hur mycket i pingskillnad servern skall försöka motverka. 0.5 motsvarar 500ms alltså en halv sekund vilket är extremt mycket idagens adsl täta sverige. Men nätkoden är ju skriven på en tid då de flesta som ens hadde internet hadde 56k. Detta värde kan snabbt tillskrivas som en bov när det gäller knockback i cs. (se knockback) Säg att en spelares paket komemr på villovägar och först kommer fram till servern 300ms efter att det skickades. Med 0.5 i sv_maxunlag kommer då servern fortfarande beräkna datan det paketen innehöll. Sådana tillfällen inträffar sällan men är en källa för riktigt sjuka skott eller missar. Bästa är att ignorera så gamla paket för att minimera risken för fel.

knockback: term använd om den effekt som kan upplevas på klientsidan då servern positionskorigerar klienten efter att någon händelse har skett. Effekten kan bli så illa av detta att man blir påskjuten av en spelare med dåligt sikte som träffar något ströskott då och då men du kan fortfarande inte röra dig ur fläcken. Eller rättare sagt du kommer en liten bite sen flyttar servern tillbaka dig till det stället träffen registrerades på. Sen får man inte glömma att vissa vapen i cs har en bra stop effekt medans andra som scout knappt känns. Alltså också lite av ett subjektiv term men som dock uppstår. Gärna uppstår denna effekten när den som skjuter på en har närmare 100 i ping eller mer.

2 Hur det funkar i cs1.6

Som förklaras under nätkod i tidigare stycke sker egentligen inget i cs1.6 i realtid. Allting sker som i ett turbaserat spel med skillnaden att alla gör sina drag samtidigt och fortlöpande. Hela tiden håller alla servern uppdaterad (se cl_cmdrate) med vad de håller på med. Servern i sin tur ligger å räknar på vad som sker för att samtidigt hålla alla klienter så uppdaterade som möjligt.
Om man sedan tar med att server tar pingskillnader i beaktning och kör en form av tillbakablick i tiden på vad som hänt för att inte folk med hög ping skall få för stor nackdel. Samt att allas klienter kör sin interpolering över alla uppdateringar de får (se ex_interp). Så borde det inte komma som någon överraskning att fel uppstår.
Viktigt för att undvika fel är att trafiken med uppdateringar till och från servern flyter på i en jämn följd. Finns många exempel på uppkopplingar som får trafiken att komma i vågor. Men för en så skön och stabil spelupplevelse som möjligt i en så gammal kod som cs1.6 faktiskt är så skall man sitta på lan eller åtminstånde har en väldigt jämn trafik mellan klient och servern.
Det finns 2 olika skolor i spel på hur man löser nätkod i spel. Den ena ger ingen pardon till högpingare och den andre ger ingen fördel till de med låg ping. Därav ger ju första skolan bäst precision, alltså att klienterna är mer synkade i förhållande till varann än den andra skolan som ser mer till att folk kan spela ihop och ha det kul.
Det man inte vill göra är att blanda dessa skolor då de fundamentalt skiljer sinsemellan. Självklart har valve skrivit in bägge 2 i nätkoden till source. I cs1.6 har jag inte läst någonstanns om att bägge skulle finnas men i de flesta fall så beter den sig samma som source så chansen finns. Felen som uppstår har med synkning mellan server och klient att göra. Oftast förskjutna hitboxar i förhållande till modelen (gubben man ser). Det kan även uppstå felplasering av modellerna.
Det man ska tänka på är att mycket utav dessa saker är sånt som bara uppstår lite då och då eller i kombination av vissa netsettings.
Det absolut viktigaste är att man har sin klient så synkad mot serverns bild av spelet som möjligt. Det är servern som bestämmer om ett skott är träff eller inte.

3 Server settings

Vad man vill uppnå är en server som håller en jämn stadig ström av uppdateringar till klienterna. För att klienterna ska vara så synkade som möjligt vill man även uppdatera dem mer än default 30ggr i sekunden. Dessutom vill man inte att servern lägger onödigt tid till pingen för spelarna.
Så det första man gör är att få upp fps'en på servern. En standard server snurrar i ca 60 till 100 fps beroende på oprativsystem. Varje frame (bild, tick) servern räknar ut klarar den av att uppdatera klienterna en gång. Det man absolut inte vill få är att fps'en på servern droppar under sv_maxupdaterate. Men om fps'en droppar under 250 efter att man boostat den så är det iaf ingen bra burk för server.
För att bli av med pingpåslaget servern har ökar man hur mycket frames (fps) servern går i. Man kan räkna såhär 1s/100fps=10ms vilket ger ett direkt påslag på 10ms på pingen om servern bara går i 100fps. 300 till 600 fps ger obetydlig pingpåslag och att köra i 1000 fps ger för snabbt spel. I 1000 fps kan det på vissa sytem slå ut serverns sätt att räkna tid vilket gör att bomben låter konstigt, exploderar snabbare än mp_c4timer står på. Har personligen en linux burk som blir helskum i 1000fps. Dessutom påverkas rekylhateringen av serverns fps. Rekylen i 1000fps brukar vara väldigt lätthanterlig vilket i sig ger fördel för de som e vana med det och samma folk som är vana med 1000fps brukar whina om hoppig rekyl på andra servar.
För att få servern att gå fortare än 100 fps krävs att man ändrar sleeptimern i oprativsystemet. Windows har default 10ms vilket gör att servern max kan gå i 100fps. Linux med senare kernel än 2.6.0 ska ha 1ms vissa distros kör dock en kernel hz på 250hz standard vilket ger max 250 fps. Då får man kompilera om kernel med 1000hz flagat/ibockat.
I windows startar man lättast upp mediaspelaren, laddar en liten avi fil. T.ex. clock.avi som finns i windows mappen nånnstans. Man behöver inte loopa den eller pausa den låt den spela genom en gång å lämna sedan mediaspelaren igång. Dessutom finns det en liten flash för just fps boostning som är väldigt smidig att köra. Har dock inte den liggandes på min burk å servern som den ligger på är avstängd så kan inte kolla namnet.
Både mediaspelaren och flashen har samma resultat. De sänker windows sleeptimer till 1ms vilket ger ett nytt maxvärde på serverns fps på 1000.
Prova att ändra sys_ticrate till 10000 och kör antingen "rcon stats" eller stats direkt i serverconsolen för att kolla vilken fps servern har. Torde vara snabbt avklarat att se om det numera är boostad eller inte.
Nästa steg är att balansera bandbredden på servern. Jag rekomenderar hjärtligt att ni kollar kvaliten på serverns lina först. Alltså hur mycket den klarar i uppload/download innan fel uppstår. Speciellt adsl linor har problem med att downloaden sjunker sanbbt när man närmar sig runt 80% av upploadens kapacitet. Men detta låter jag er avdöma själva. en annan sak man kan kolla är att se hur mycket pingen fluxar (hoppar) från server burken mot några referens ställen. T.ex sunet. En alltför fluxande ping tyder på att det kan bli problem att få en fin jämn ström av uppdateringar till klienterna. Att tänka på är att ping paketen är låg prioritet på så några enstaka utstikare kan man leva med.
Som minst kan man säga att man behöver 3Mbit i uppload för att köra en stabil warserver i uppställt läge. Anledning till att du vill ha en tilltagen buffer i uploaden är just för att när du når en viss gräns på upploaden så börjar trafiken bli ryckig. Dessutom om du ligger för nära upploadens max får du pingtoppar när den tar slut. Dessa kommer ju då självklart när saker händer och mycket ska uppdateras på klienterna. Att då få över 300 i ping ger ingen spelglädje. Därav bufferten.
Ett smidigt sätt att börja är i toppen för att se vart den svaga delen i länken är. Och med det menar jag att man sätter upp allt på servern till lansettings.
Detta inkluderar....
sv_maxrate 20000
sv_maxupdaterate 100
Kolla och laborera sedan med sys_ticrate för att få en stabil fps mellan 300 och 500 i obelastat läge. Sedan är det dags att kolla om linan pallar trycket med 100 uppdateringar i sekunden. Problemet är att man måste ha tag på folk som kör rätt rates på sina klienter. Genväg är att slå på ett par i maxplayers och köra den som public. En map som aim_ak-colt är ett bra test då den lägger tung press på linan då nästan alla klienter ska ha info om alla andra klienter hela tiden.
Under testkörning håll koll så att fpsen inte droppar under 250 för att säkerställa att ping och uppdateringar inte ska påverkas av serverns prestanda.
Använd sedan net_graph 1 för att kolla trafikens kvalite. Viktigt är att du har rätt inställningar för att se rätt info. Kolla in avsnittet nedan om att synka sin klient mot servern.
Om nu både server och lina håller är det bara sista och viktigaste steget kvar, att ställa in rätt känsla på servern.
För att påverka serverns känsla får man laborera med dessa inställningar. Rekomenderar att börja på de som jag skrivit.
sv_maxupdaterate 100 (100 kanske inte är optimalt om trafiken kanske kommer ojämnt då)
sv_minupdaterate 30 (kanske inte det viktigaste men kan prova att ställa upp den till 40 eller 50)
sv_unlag 1 (kan va kul att labba lite med för att se skillanden. Dock marginell skillnad ifall klienterna liger under 40 i ping)
sv_maxunlag 0.15 (default 0.5 vilket säger att packet från så långt tillbaka som en halv sekund skall beräknas)
sv_minrate 3500 (att tvinga servern att skicka mer och större paket än nödvändigt kan inte va bra, eller? )
sys_ticrate (absolut viktigaste för känslan Fluxande fps kan ge kraftiga synk problem med släpande hitboxar i som resultat trots korrekt inställd klient)

Vissa av dessa inställningar kan inte ändras under spelets gång utan kräver omstart av mapen för att träda i kraft. T.ex sv_maxupdaterate. Det att hitta rätt inställningar kan ta tid. Och har man inte en perfekt lina kan man va tvungen att saka lite precision för att få ett mer flytande spel. Allt detta handlar dock mycket om små skillnader i millisekunder osv så allt e lite suspekt att göra. Viktigaste är att fpsen ligger så stabilt som möjligt och att linan inte pressas över gränsen av vad den klarar av sedan kommer varje klients egna inställningar in i bilden och de kan påverka mycket också.

4 Att synka sin klient mot servern

Om du har läst det som står ovan så börjar du nog få en malande tanke i bakhuvudet om att det du ser på skärmen inte alltid är det servern ser. Detta kan mycket väl stämma men nu ska vi kolla på att synka din klient mot servern så att det du ser på din skärm är så synkad mot serverns bild av spelet som möjligt.
Målet är att nå en kompromis mellan det din klient beräknar fram och det du får från servern som faktiska uppdateringar. Som exempel kan man förklara så här. Du spelar på en default server med 30 uppdateringar i sekunden. Du tittar på en spelare som på en sekund springer i en cirkel. Alltså ifrån start på cirkel tills spelaren kommit hela varvet har en sekund flytit. på den sekunden har du från servern fått 30 uppdateringar om vart spelaren befinner sig och vart han är på väg. Dessa uppdateringar kan du tänka dig som 30 punkter jämnt fördelade på cirkeln. Mellan dessa punkter är det din egen klient som fyller på luckorna. Detta kallas interpolering. Att interpolera mer än vad som krävs kan snabbt leda till förskjutna hitboxar. Då oftast släpande hitboxar. Alltså för att träffa måste man skjuta lite bakom rörliga mål. Detta är mycket förekomande på servrar som kör 70 eller mer uppdateringar samt hlguard som låser upp folks ex_interp på 0.1 som är default.
För att börja i rätt ände så börjar man med lan inställningar.
cl_cmdrate 100
cl_updaterate 100
rate 20000
ex_interp 0 (viktigt skall sättas efter cl_updaterate)

När ex_interp sätts till 0 räknar cs själv ut det optimala värdet på ex_interp. Formeln lyder 1s/cl_updaterate=ex_interp. Men nu med cl_updaterate 100 så kanske detta inte är optimalt då serverns sv_maxupdaterate kanske är ställt lägre. Det är nu vi tar net graphen till hjälp.
skriv "net_graph 1" i consolen utan " då

texten som står är som följer.
Fps övre vänstra hörnet
ms mitten överst är ping fast ändå inte. Den går få bort men man har iaf ping ju.
in/out Hur mycket trafik som går in/ut från klienten. Mäts i Kilobyte i sekunden.
cl_updaterate står i övre högra hörnet
cl_cmdrate står nere till höger

Det grafiska är..
Gröna strecket är pingen. de små gröna markeringarna på sidorna mostvarar 0 i ping
De gulvita prickarna under strecket är luckor i interpoleringen
det blåa i nederkan är där interpolering räcker till

Netgraphen indikerar att man har ett för lågt interpoleringsvärde för det antal uppdateringar man får från servern. Det man då gör är att sänka cl_updaterate stegvis. Nu vet jag sen tidigare att denna server som jag tagit screenshotsen på kör default sv_maxupdaterate 30 eller något värde väldigt nära 30 iaf.

Om vi då sänker cl_updaterate till 50 så kommer vi ju närmare sv_maxupdatevärdet vilket borde va bättre. Eller?

Det man genast ser är att vi bara får enstaka luckor i interpoleringen. Ms värdet är dessutom halverat av någon anledning. Och värdet för cl_updaterate i övre högra hörnet visar nu 50. De blå prickar na visar mycket jämnare form. Detta skulle kanske duga. Om man fortfarande upplever det som ryckigt kan man sänka lite till.

Ms helt borta någon enstaka interp prick de blå visar bra form för en 30uppd/s server

Genomgående på dessa ligger jag i specc och har en stadig ström av uppdateringar som motsvarar ca 2.65Kb så dessa inställningar har inte påverkat min trafik till från server utan bara min klients hantering av interpoleringen.

Personligen tycker jag iaf det är svårträffat och luddig känsla på en sådan server men efter att dessutom sänkt cl_cmdraten till 62 (ca sv_maxupdaterate x 2) började även jag träffa. Fick då även tillbaka ett litet rött stråk av prickar längst ner i net_graphen som jag brukar ha på våran 100uppd/s server.

En sak att tänka på är att ingen interpolering utförs på server sidan vilket gör att om du gör sparsamm interpolering och det springer runt folk med cl_cmdrate 10 till 20 (10 e minsta man kan ha). Kommer de vara ryckiga som bara den. Sådana ser man dock väldigt sällan i klanspel sammanhang. När folk gått så långt att de börjar snegla på klanlir har de oftast snappat upp standard inställningen för en klient på 101/101/25000.

Angående hlguard och net_graph 0.1.
Har ingen som helst förståelse för varför de som gör hlg fortf. envisas med att låsa detta standard värde då det i ligor och seriöst spel är tillåtet. Detta är inget cheat om man inte kallar det cheat att få bättre träffregistrering på grund av en mer synkad bild av spelet jämnfört med serverns bild av spelet. Men med 2 snabba editeringar av hlg's cvar listor för Hl och CS så är det löst. Och du har en fungerande HLguard som inte låser interpen.

5 Slutord

Mycket av detta grundas på egna iaktagelser men även på research i ämnet. Vissa saker som maxraten 20000 och hur interpoleringen funkar är hämtat ifrån intevjuer med valvefolket som skrev koden. Dock har flera ominstallationer gjort att jag tappat bort referens matrialet. Så jag ger inga källor till det jag skrivit ni får testa själva och skaffa er en egen uppfattning. Viktigaste är iaf att ni har trevligt. Jag säger heller inte att allt som står ovan är 100% rätt. Vissa saker vet jag är rätt andra är sånt som kommit genom laborering och slutledningsförmåga.
Glöm heller aldrig att ni spelar ett 8 år gammalt spel som bara putsats lite på.

Skrivet av JustMe

Copyright osv tillhör MuNgLo
Publisering utan tillstånd beivras medelst tk

Inaktiv

Bra skrivet!

Just att jag är lite osäker på att läsa av min net_graph, vet inte vilket av följande resultat som är bäst:

Länk till bilden ovan

Vilken av bilderna är bäst resultat på? Den till vänster eller den till höger?

1
Skriv svar