IndledningFormålet med denne guide er at introducere Netcode i CS:Source. Som seriøs spiller er det væsentligt, at man kender til Netcode, herunder hvilke indstillinger der er mest hensigtsmæssige at køre med. Derfor vil guiden både gennemgå, hvad Netcode er, hvilke problemer der er, samt til sidst komme med anbefalinger til, hvilke kommandoer man bør køre med,
Selvom Netcode kan være svært at forklare uden brug af en masse engelske termer, forsøger vi alligevel med til tider alternativ oversættelser. Vi har før været inde omkring Netcode, herunder interpolate-kommandoen (se guide), men da vi finder det nødvendigt med en mere uddybende artikel omkring emnet (også i lyset af at LAN arrangementer nærmer sig), mener vi, der er brug for denne guide.
Hvad er NetcodeKort sagt kan Netcode beskrives som den måde, hvorpå den computer, man spiller fra (omtales klient i det følgende), og server kommunikerer. Klient og server kommunikerer naturligvis med hinanden, når man spiller, ved at sende små datapakker (data packets).
| | Klienter modtager en masse information om, hvad der sker på serveren, hvorudfra der genereres video og lyd.
| | | Serveren modtager data om, hvad du foretager dig med keyboard, mus og mikrofon, og bearbejder disse data.
|
Denne kommunikation sker kun imellem server og klienter, og der er således ingen direkte kommunikation imellem klienter. Alle disse data sendes igennem datapakker (packet-based communication), og det er her, Netcode har dens funktion.
Eftersom mængden af data, der kan sendes imellem server og klienter er begrænset, så kan serveren ikke opdatere klienterne om enhver ændring, som der sker på serveren. Derfor tager den nogle øjebliksbilleder (snapshots) og sender videre til klienterne. De allerede omtalte datapakker tager en vis tid at transportere imellem server og klient, hvor ping'en er en faktor. Disse to forhold - begrænset mængde af data, der kan sendes, samt forsinkede datapakker - gør, at klienten altid er bagud i forhold til serveren. Med andre ord er det, du ser på din skærm, forsinket, i forhold til det, der i virkeligheden sker på serveren. Her snakker vi om milisekunder. Denne forsinkelse bliver dog ikke mindre af, at nogle datapakker mistes i trafikken mellem server og klient.
I hurtigere FPS spil såsom CS:Source kan bare få milisekunders forsinkelse skabe en følelse af et laggy gameplay. Derfor kan det være svært at ramme andre. I yderst led kan en dårlig opsat server og en stardard klient config betyde, at hitboxes er så forsinkede som illustreret nedenfor:
Valve har ved forskellige teknikere formået at løse disse problemer med forsinkelse - eller i det mindste gjort dem mindre synlige for spillere. Med en samlet betegnelse kan teknikerne betegnes som en klient/server-netværksarkitektur - eller bare Netcode, som oftest bruges på forskellige fora.
Problemer med NetcodeSource Engine'en simulerer spillet ved forskellige ticks, som ved en stardardopsat server er 33 ticks per sekund (tickrate 33 server). Ved hvert eneste tick opdateres det, der sker på serveren. Jo flere ticks per sekund, desto bedre kan spillet simuleres. Men en tickrate 100 server tager derimod også betydelig mere cpu kraft end en tickrate 33. Ligesom en højere tickrate kræver mere af den computer, en server står på, så kræver en højere tickrate også en større mængde data fra klienterne. Sidder man eksempelvis bag en modem, vil man i værste tilfælde kun kunne modtage 5-7 kb per sekund, hvilket vil betyde, at en masse datapakker går tabt. Det er kommandoen rate (kb/sec), der bestemmer, hvor store disse datapakker skal være. Det er derfor meget vigtigt, at denne kommando er sat korrekt. Udover rate-kommendoen bestemmer cl_updaterate, hvor mange øjebliksbilleder per sekund, man ønsker tilsendt. Hvorimod cl_cmdrate angiver, hvor mange datapakker per sekund, man vil sende til serveren.
Efter denne meget korte introduktion til tickrate, rate, cl_updaterate og cl_cmdrate, vil det nedenstående afsnit koncentrerer sig om de to store problemer, der er med netværksarkitekturen.
Hvis man kører med en standard config fil, modtager klienter 20 øjebliksbilleder per sekund, altså hvert 50. milisekund (cl_updaterate 20). Eftersom gameplay'et vil virke meget laggy med så få billeder, går spillet tilbage i tiden for bruge tidligere øjebliksbilleder til at gøre billedet flydende. Det forklares bedst med nedenstående citat:
By default, the client receives about 20 snapshot per second. If the objects (entities) in the world were only rendered at the positions received by the server, moving objects and animation would look choppy and jittery. Dropped packets would also cause noticeable glitches. The trick to solve this problem is to go back in time for rendering, so positions and animations can be continuously interpolated between two recently received snapshot.
Denne teknik kaldes "entity interpolation". Det interessante er, at Source - med en normal config - interpolere over en periode på 100 milisekunder (cl_interp 0.1), som nedenstående illustration viser (klik på billedet for at gøre det stort):
Hvis et billede bliver tabt i trafikken mellem server og klient, vil spillet tage det forrige billede. Men pointen er - med cl_interpolate 1, at der altid vil være 100 milisekunder forsinkelse, når cl_interp er på 0.1, som er den mindste værdi, den kan sættes på. Dette er det ene problem.
Det andet problem opstår, når cl_interpolate er slået fra (på 0). Her vil der ikke være en forsinkelse på 100 milisekunder i og med, at interpolate teknikken er slået fra. Derimod vil gameplay'et virke laggy. Selvom cl_interp forsinkelser ikke længere er der, så vil der alligevel være en meget lille forsinkelse - hvad enten man spiller på samme computer, som serveren er på, eller ej. Det er desværre ikke noget, vi kan forklare, men du kan selv udforske det ved at lave en server og skrive følgende kommandoer i konsollen:
| | bot_add_ct
| tilføjer en bot (skal være på samme hold som en selv)
| | | sv_cheats 1 | muliggør cheat kommandoer | | | mp_friendlyfire 1 | friendly fire
| | | cl_interpolate 0 | deaktiverer interpolate i spillet | | | bot_mimic_yaw_offset 360 | Disse to kommadoer gør, at botten foretager
det samme som en selv
| | | bot_mimic 1 |
Start med at gå sidelæns, når du starter foran botten, mens du sigter på bottens hoved - og skyd. Placer derefter sigtekornet lige bag ved bottens hoved, gå sidelæns igen og skyd. Derefter vil du se, at botten mister health, som betyder, at hitboxes ikke er optimale, da du jo ikke ramte hovedet. Trods dette, er det langt fra et så stort problem, som forsinkelsen ved cl_interpolate 1. Og indtil nu har vi ikke fundet en forklaring på dette problem.
Hvilke indstillinger ingame?Spørgsmålet er så, hvad man skal bruge ingame - interpolate 1 eller 0. I starten af CS:Source's levetid valgte de fleste at bruge cl_interpolate 0, idet forsinkelsen var meget mere beskeden uden interpolate end med - det er den i øvrigt også i dag efter mange opdateringer af Source Engine. Såfremt kampe bliver spillet på tickrate 100 servere, så vil det mest optimale være at køre uden interpolate, fordi man hermed undgår den 100 milisekunder forsinkelse, og spillet kører nogenlunde flydende på grund af de mange ticks per sekund. Alligevel er cl_interpolate 1 blevet det mest acceptable at kører med efter mange diskussioner omkring emnet. Dette er også blevet hjulpet godt på vej af server plugins såsom zblock max (findes i download sektionen), der blokkerer for cl_interpolate 0.
Det er især folkene bag online og LAN arrangementerne, der har sat standarden for fairplay i dette spørgsmål. Det kan dog virke besynderligt, at det er netop er interpolate 1, der er blevet valgt. Sagens kerne er dog, at en bestemt værdi af interpolate er blevet accepteret på scenen. Hvis dette ikke var tilfældet, ville de, der kørte med interpolate 0, have en betydelig fordel over for de, der kører med interpolate 1.
Det er nok ikke alt, man som læser forstod af denne artiklen, eftersom emnet er ret teknisk og dermed vanskeligt at forklare. Derfor sluttes artiklen af med at nævne de indstillinger, man som fairplay-spiller bør have i sin autoexec.cfg, se CS:S guide til begyndere (bemærk at disse er minimum-indstillinger, oftest medtages cl_smooth 1):
| | cl_interpolate "1"
cl_interp "0.01"
cl_updaterate "100"
cl_cmdrate "100"
rate "25000" (hvis man har en bredbåndsforbindelse)
|
Benytter man sig ikke af disse indstillinger, vil det oftest hurtigt blive opdaget af ens modstandere, da de fleste erfarne spillere kan se forskel på henholdsvis dårlige og optimale klient-indstillinger, når det handler om netcode. For de dovne, som ikke har disse indstillinger, har vi uploaded en autoexec.cfg fil til download sektionen under navnet "Autoexec (netcode commands)".
Vil man læse mere om Netcode, så er de to artikler, der er linket til nedenfor, en udemærket introduktion. Endvidere er man meget velkommen til at stille spørgsmål her nedenfor.
Link(s):Counterstrike source netcode - The final quirks
Source Multiplayer Networking
|
