Hallo Frischling! Schön, dass du uns besuchst.
Du hast leider nur eingeschränkte Zugriffsrechte und siehst auch nicht alle Inhalte dieser Page. Bitte melde dich an bzw. registriere dich, um alle Funktionen auf unserer Page nutzen zu können.
Wir sind außerdem nicht dazu Verpflichtet jede Idee anzunehmen, wir müssen schauen das zwischen Anti-Terrorist und Terrorist eine art Balance bleibt. (Das beide Teams eine chance haben zu gewinnen)
Wie wäre es dann mal mit einem funktionierenden Auto-Team-Balance? Meistens dominiert eine Seite. Es werden kaum bis keine oder halt die falschen Spieler geswitched, sodass manche dann selbst wechseln wollen, um es auszugleichen.
sorry aber was ich like entscheide ich noch selbst. Ich like Vorschläge die ich gut finde. Die Diskussion unter euch interessiert mich nicht wirklich. Und ich habe sie Erfahrung von damals noch, das selbst bei kurzen Rundenzeiten gecampt wird.die echten Camper juckt das nicht.und wenn ct tauschen und früh sterben sind sie es auch selber schuld.also ich meine direkt ruhen ohne mal zu warten.
Ich glaub du hast seinen Punkt immer noch nicht verstanden. Das gecampt wird, wird auch mit einer kürzeren Rundenzeit der Fall sein, aber der Rest muss dann nicht mehr so lange auf die Camper warten, bis was passiert oder die Zeit abläuft. Ob man die Zeit auf 1:30 verkürzen sollte wäre meiner Meinung nach in Ordnung, aber man könnte wenigstens von 2:30 auf 2 Minuten runter gehen. Da haben die Ts immer noch genug Zeit zu verschieben und umzuplanen.
Ich soll einen wert der bei 60 steht auf 0 stellen ohne zu wissen was dieser tut? niemals. Man kann es in 10er schritten nach unten versuchen.
Weil man bei 10er Schritten auch wirklich einen Unterschied feststellt. Es ist nicht gänzlich unbekannt was der Wert tut und es gibt die Erfahrungswerte aus dem Internet, wo berichtet wird, dass ein Wert von 0 völlig in Ordnung ist. Ich hab dir den Wert so gut wie möglich erklärt.
Man könnte bei cl_interp doch genauso argumentieren, da ist doch auch geplant, dass dieser drastisch vom Standardwert 100 ms auf 15-30 runter gestellt wird.
Du tust gerade so, als ob man die Variable nicht schnell wieder ändern könnte und dir bei falscher Einstellung der Server abfakelt...
Aber gut eure Server, euer Vorgehen. Ich frage mich dann nur in welchem Zeitraum man in den 10er Schritten runtergeht.
Danke für die Idee, was genau macht "sv_clockcorrection_msecs"? das mit den Flashes wurde mir auch von einem Admin gesagt, könnte man drüber nachdenken. (in cs2 gibts ja auch nur noch 1 flash)
Danke für den Vorschlag ,der "geht in deckung sound" wurde zwecks gespamme deaktiviert, weiß nicht ob das sinnvoll ist ihn wieder zu aktivieren. Muss ich mir anschauen.
Ganz genau kann ich es dir leider auch nicht sagen. So wie ich verstanden habe, hat das mit der Jitter-Korrektion zu tun. Also ein zusätzlicher Wert um Pingschwankungen abzufangen. Der Standardwert ist 60, aber ich denke nicht, dass jemand mit einer normalen Internetleitung Pingschwankungen im Bereich von 60 ms hat.
Das Problem ist, dass das zu weiteren Verzögerungen des Game State der anderen Spieler, des Servers und zu einem selbst führt. Ähnlich in der Funktionsweise wie Lag Compensation und Interpolation (cl_interp).
In CSGO (CS2 weiß ich nicht), war der Standardwert schon runter auf 30, wenn ich mich nicht irre. Man könnte mindestens auf den Wert 30 bei euch runter gehen, wenn nicht sogar auf 15. In dem was man dazu online findet, werden oft auch DM Server erwähnt (CSS wie CSGO), die das auf 0 gestellt haben und es sich trotzdem gut spielt.
Ein Kompromiss wäre ein Wert von 15-30 ms, aber ich wäre fast dafür, dass man das auf 0 stellt und dann vielleicht mal ne Woche zum Test laufen lässt.
Wenn es Beschwerden gibt, die man genau dem zuordnen kann, kann man es ja wieder höher stellen.
Gruß
PRESSIVE
Moin,
wie zuvor schon mal erwähnt könnte man mit der Server CVAR "sv_clockcorrection_msecs" rumspielen. Von Standardwert 60 runter auf 30 oder sogar 0. Spielt sich evtl etwas runder auf dem Server dann.
Bei den Maps fällt mir nur Tuscan ein, weil das meine Lieblingsmap von damals ist, aber ich denke die ist für Public nicht geeignet. Allgmein gibt es wahrscheinlich wenige Maps, die sich mit 20-30 Spielern noch gut spielen. Wobei das auch schon auf dem Dust2 Server kritisch ist, da die Hälfte der Runde erstmal nur aus Nadespam besteht und das richtige Spiel erst wirklich losgeht, wenn die meisten ihre Nades schon geworfen haben. HEs zu begrenzen wird schwierig, aber man könnte auf eine Flash pro Spieler runtergehen.
Gruß
PRESSIVE
PS: kurz vor 5 Minuten (Tick ~19600) zuckt er auch kurz was nach aimer aussieht, aber tritt leider nur einmal auf.
Hier meine Demo von gestern:
https://www.mediafire.com/file/sqd9evpi0qhnalq/ekon.dem/file
Einfach mal anschauen. Und dann evtl nochmal mit folgenden Commands:
sv_cheats 1 (braucht man für die Commands unten)
sv_showimpacts 1 (zeigt einem wo Schüsse eintreffen + Hitbox, zumindest das clientseitige)
r_drawothermodels 2 (macht Gegner durch Wände sichtbar)
r_drawparticles 0 (macht Smokes unsichtbar)
Am besten auch nicht mit 100er Lerp anschauen, glaube der spielt mit niedrigerem.
cl_updaterate 66
cl_interp_ratio 1
cl_interp 0 (das allein zu setzen sollte eigentlich schon reichen, aber sicherheitshalb den Rest oben auch setzen)
Der Lerp macht bei Demos auch einen Unterschied und lässt manche Sachen komisch aussehen, wenn es nicht so eingestellt ist, wie bei dem Spieler den man beobachtet wie sonst auch.
Bin mir nicht genau sicher was es ist. Sieht bisschen nach silent aim aus und dann aber zieht er zu manchen Gegnern ruckartig hin. Fakt ist auf jeden Fall, dass er oft nicht dahin schießt, wo die Gegner sind, meistens auch noch im Laufen auf große Distanzen und irgendwie trotzdem seine Schüsse (oder ein paar davon) treffen.
WH bin ich mir auch nicht 100% sicher, aber gegen Ende scheinen ihn wohl Smokes auch nicht zu interessieren und er guckt Leute durch Wände an oder zielt vor. Die Demo ist nicht lange mit 7 min und die letzten zwei Minuten kann man sich sparen.
Ich hoffe mal das reicht, clean ist der Typ nicht. Das er dumm wie Brot spielt macht die Sache etwas schwerer.
Gruß
PRESSIVE
Der Typ hat außerdem mindestens zwei Accounts.
https://noaim.gameme.com/playerinfo/585825
https://noaim.gameme.com/playerinfo/604782
red_bairN und BalduR hatten glaub ich auch Demos.
Generell, unabhängig der Uhrzeit. Bei mir zumindest Mikroruckler, manchmal "größere lags", es fühlt sich alles irgendwie verzögert an. Ping ist stabil und auch niedriger als beim alten Server.
Keine Highpings bis jetzt aber dafür generell wie Schröder schreibt, nicht mehr so flüssig. Hab ich von zwei weiteren Leuten auch gesagt bekommen.
Vielleicht tut es auch ein einfaches "return Plugin_Handled" oder "return Plugin_Stop"?
public Action Event_OnFlashPlayer(Handle event, const char[] name, bool dontBroadcast)
{
if(g_bEnabled)
{
int client = GetClientOfUserId(GetEventInt(event, "userid"));
if(!client || !IsClientInGame(client) || g_bDisable) return Plugin_Continue;
if(!g_bAlive[client])
{
if(g_bSpec && g_iTeam[client] <= CS_TEAM_SPECTATOR || g_bDead && g_iTeam[client] >= CS_TEAM_T)
SetEntPropFloat(client, Prop_Send, "m_flFlashMaxAlpha", 0.5);
}
else
{
int _iData[2];
if(GetArraySize(g_hEntities) == 0) return Plugin_Continue;
GetArrayArray(g_hEntities, 0, _iData);
if(g_iTeam[client] == _iData[1])
{
if(!g_bOwner && _iData[0] == client) return Plugin_Continue;
//if(g_bTeam) SetEntPropFloat(client, Prop_Send, "m_flFlashMaxAlpha", 0.5);
if(g_bTeam) return Plugin_Handled; // if(g_bTeam) return Plugin_Stop;
}
}
}
return Plugin_Continue;
}Was ich noch nicht so ganz herausfinden konnte, ist ob diese zwei Rückgabewerte nur die HookChain innerhalb von SourceMod stoppen/halten (im Zusammenspiel mit anderen Plugins) oder ob diese tatsächlich verhindern, dass etwas an den Client gesendet wird.
Aber falls das der Fall ist, könnte man so die Teamflash ohne viel Code auf Clientseite ganz verhindern. Man hat dann nicht mehr diesen ultraleichten Flasheffekt wie dafür, wenn man eine Teamflash abbekommt oder im Spec bzw. tot ist, aber das würde ich eher in Kauf nehmen, als dass es Gegnerflashes wieder entfernt.
PS: Die Funktion CancelCreatedEvent() gibt es auch noch. Vielleicht könnte man damit auch das "player_blind" Event ganz verhindern.
Vielleicht kann man ja etwas von dem Code für das ForceRate Plugin ableiten, aber dazu muss ich den Code erstmal sehen. Würde mich eh stark interessieren, wie du das umgesetzt hast. Eventuell kann ich etwas dazu beitragen, im worst case habe ich was dazu gelernt.
Hallo zusammen,
ich schon wieder ^^. Da mein letzter Post direkt geschlossen wurde, greife ich folgendes hier erneut auf:
1. Könnte ein Colorchanger für die Smokes (https://forums.alliedmods.net/showthread.php?p=1613820) eventuell das Problem mit den Bugsmokes eliminieren? Habt ihr das schonmal ausprobiert? Auf einem DM Server auf dem ich und zu spiele, werden grüne und blaue smokes verwendet und dort habe ich bis jetzt keine Bugsmoke gesehen. Man kann die natürlich auch wieder grau färben.
2. Mit "sv_clockcorrection_msecs" ging es mir ja darum, dass es nicht auf default gesetzt ist, sondern dass man den Wert auf 0 setzt oder wenigstens reduziert.
3. Wie viele Server FPS bekommen eure CS:S Server? Wenn diese zu hoch oder zu niedrig sind, kann es zu einem unrunden Spielerlebnis führen. Zu niedrig wäre beispielsweise unter der Tickrate, und zu hoch Werte wie 1000 oder darüber, wo der Server nicht mehr mithalten kann.
Gruß
PRESSIVE
Pastebin zum ganzen Plugin Code: https://pastebin.com/Pk8tD34q
Um jetzt zu erreichen, dass ein vorheriges "Geflashtsein" berücksichtigt wird, habe ich folgende Ergänzungen vorgenommen:
Handle g_hTimerDisable = INVALID_HANDLE;
Handle g_hFlashTimer[MAXPLAYERS + 1];
bool g_bEnabled, g_bTeam, g_bDead, g_bSpec, g_bOwner, g_bDisable, g_bOverride, g_bLateLoad, g_bAlive[MAXPLAYERS + 1];
float g_fDisable, g_fLife;
int g_iTeam[MAXPLAYERS + 1], g_iFlashStartTime[MAXPLAYERS + 1];
...
public void OnMapEnd()
{
if(g_bEnabled)
{
if(g_hTimerDisable != INVALID_HANDLE && CloseHandle(g_hTimerDisable)) g_hTimerDisable = INVALID_HANDLE;
ClearArray(g_hEntities);
// ClearArray(g_hFlashTimer);
for(int i=0; i < MAXPLAYERS; i++)
{
if(g_hFlashTimer[i] != INVALID_HANDLE)
{
CloseHandle(g_hFlashTimer[i]);
g_hFlashTimer[i] = INVALID_HANDLE;
}
}
}
}
...
public Action Event_OnFlashPlayer(Handle event, const char[] name, bool dontBroadcast)
{
if(g_bEnabled)
{
int client = GetClientOfUserId(GetEventInt(event, "userid"));
if(!client || !IsClientInGame(client) || g_bDisable) return Plugin_Continue;
if(!g_bAlive[client])
{
if(g_bSpec && g_iTeam[client] <= CS_TEAM_SPECTATOR || g_bDead && g_iTeam[client] >= CS_TEAM_T)
SetEntPropFloat(client, Prop_Send, "m_flFlashMaxAlpha", 0.5);
}
else
{
int _iData[2];
if(GetArraySize(g_hEntities) == 0) return Plugin_Continue;
GetArrayArray(g_hEntities, 0, _iData);
if(g_iTeam[client] == _iData[1])
{
if(!g_bOwner && _iData[0] == client) return Plugin_Continue;
if(g_bTeam)
{
if(g_iFlashStartTime[client] > 0)
{
// Wenn der Client bereits geflasht ist und die Flash Duration noch nicht abgelaufen ist,
// dann berechnen wir die "Geflashtheit" anhand
// eines Zeitstempels und setzen diese als Startwert für die nächste Flash
// (in der Annahme die Flashanimation ist linear)
g_fFlashDur = GetEntPropFloat(client, Prop_Send, "m_flFlashDuration");
curTime = GetSysTickCount(); // GetTime()
int curFlashDur = curTime - g_iFlashStartTime[client];
// Sollte eigentlich immer der Fall sein...
if(curFlashDur < g_fFlashDur)
{
// "m_flFlashMaxAlpha" kann maximal den Wert 255 haben
float newFlashDur = (curFlashDur / (g_fFlashDur * 1000)) * 255;
SetEntPropFloat(client, Prop_Send, "m_flFlashMaxAlpha", newFlashDur);
}
}
else
{
SetEntPropFloat(client, Prop_Send, "m_flFlashMaxAlpha", 0.5);
}
}
}
else
{
// Timer "zurücksetzen" (löschen, einen neuen anlegen) und damit die Flash Duration zurücksetzen,
// wenn die nächste Gegnerflash kommt,
// bevor die vorherige abgelaufen ist -> Timer nach hinten verschieben
if(g_hFlashTimer[client] != INVALID_HANDLE)
{
CloseHandle(g_hFlashTimer[client]); // KillTimer()
g_hFlashTimer[client] = INVALID_HANDLE;
}
// Hier merken wir wann ein Client geflasht wurde
g_iFlashStartTime[client] = GetSysTickCount();
// Man könnte auch eine weniger flexible Konstante verwenden, anstatt sich das jedes Mal neu zu holen;
// Wert in Sekunden
g_fFlashDur = GetEntPropFloat(client, Prop_Send, "m_flFlashDuration");
// Timer der nach der Flash Duration den Status "Flashed" wieder zurücksetzt
g_hFlashTimer[client] = CreateTimer(g_fFlashDur, Unflash_Player, client);
}
}
}
return Plugin_Continue;
}
...
public Action Timer_Flash(Handle timer)
{
g_bDisable = true;
g_hTimerDisable = INVALID_HANDLE;
}
...
public Action Unflash_Player(Handle timer, int client)
{
g_iFlashStartTime[client] = 0;
// Brauchen wir das?
// return Plugin_Stop;
}Kurze Erklärung (zusätzlich zu den Kommentaren im Code):
Wenn ein Spieler durch einen Gegner geflasht wurde, dann merke ich mir die "Systemzeit", wann das passiert ist, für diesen Spieler in einem Array. Zusätzlich wird ein Timer gestartet, der die Zeit des "Geflashtseins" abwartet und ihn dann wieder aus der Liste nimmt (genau genommen die Zeit des Flashens auf 0 setzt). Wenn der Spieler daraufhin, während er noch geflasht ist, eine Teamflash abbekommt, finden wir einen Eintrag (eine Zeit) in diesem Array. Anstatt den Spieler jetzt einfach zu "Entflashen", berechnen wir anhand der bereits abgelaufenen Zeit des "Geflashtseins" die restliche "Geflashtheit" aus. Diese wird dann als Startwert für die nächste Flash (in dem Fall eine Teamflash) weitergegeben. Damit wird die Teamflash nicht gecancelt, sondern nimmt die Eigenschaften der vorherigen Gegnerflash an und führt diese weiter.
Wenn jetzt aber nach der ersten Gegnerflash, während der Spieler noch geblendet ist, eine zweite Gegnerflash kommt, wird quasi die Flashdauer verlängert. Es muss erneut die gesamte Flashdauer abgewartet werden bis wir den Spieler als nicht geblendet vermerken.
Dieser Ansatz könnte das Problem stark mildern. Perfekt wird es nehme ich mal an nicht sein, aufgrund von Ping/Pingschwankungen, Timerungenauigkeiten, etc.
Bedenken habe ich aber noch einige, da ich hier mit vielen Annahmen gearbeitet habe und mich höchstwahrscheinlich in diesen irre. Ich gehe davon aus, dass die Flashdauer einen Maximalwert hat und bei jeder Gegnerflash mit diesem Wert angefangen wird. Das gilt auch für das "Geflashtsein".
Ich bin mir aber ziemlich sicher, dass dem nicht so ist und bspw. die Flashdauert in irgendeiner Weise addiert wird, wenn man nacheinander mehrere Gegnerflashes abbekommt. Ich denke man ist nach mehreren Flashes, die man direkt ins Gesicht bekommt länger blind als durch eine, die man direkt abbekommt.
Selbes Spiel beim Geflashtsein, denke das ganze wird dynamisch vom Server/Spiel pro Flash pro Spieler berechnet. Denn eine Flash zu der man etwas Distanz hat, wird einen nicht die volle Dauer flashen und nicht mit voller Stärke treffen.
Auch gehe ich davon aus, dass die Flashanimation von 100 -> 0 linear verläuft, aber da bin ich mir auch nicht ganz sicher.
Nur kenne ich diese Formeln nicht, sonst könnte man das miteinfließen lassen. Vielleicht findet man etwas im SourceSDK. Ich hab keine Ahnung.
Wisst ihr vielleicht etwas dazu? Kann man mit meinem Post etwas anfangen?
PS: Musste den Post jetzt kürzen bzw. aufteilen, da zu lang...
PS 2: Ist es nicht möglich etwas farblich in einem Codeblock zu hinterlegen?
Gruß
PRESSIVE
Nun zum Eigentlichen:
Wie man in der Ursprungsversion des Plugins sehen kann, wird das "Geflashtsein" mehr oder weniger direkt mit der ersten Teamflash gecancelt (FlashAlpha wird von maximal 255 auf 0.5 reduziert; 0 ist Minimun).
Es spielt keine Rolle, ob der Spieler bereits durch eine Gegnerflash geblendet wurde.
public Action Event_OnFlashPlayer(Handle event, const char[] name, bool dontBroadcast)
{
if(g_bEnabled)
{
int client = GetClientOfUserId(GetEventInt(event, "userid"));
if(!client || !IsClientInGame(client) || g_bDisable) return Plugin_Continue;
if(!g_bAlive[client])
{
if(g_bSpec && g_iTeam[client] <= CS_TEAM_SPECTATOR || g_bDead && g_iTeam[client] >= CS_TEAM_T)
SetEntPropFloat(client, Prop_Send, "m_flFlashMaxAlpha", 0.5);
}
else
{
int _iData[2];
if(GetArraySize(g_hEntities) == 0) return Plugin_Continue;
GetArrayArray(g_hEntities, 0, _iData);
if(g_iTeam[client] == _iData[1])
{
if(!g_bOwner && _iData[0] == client) return Plugin_Continue;
if(g_bTeam) SetEntPropFloat(client, Prop_Send, "m_flFlashMaxAlpha", 0.5);
}
}
}
return Plugin_Continue;
}Hallo zusammen,
ich habe mich mal bisschen in die Materie (SourceMod) eingelesen und das bereits existierende Plugins "Anti Team Flash" entsprechend angepasst.
Link zum Plugin: https://forums.alliedmods.net/showthread.php?t=139505
Link zur verwendeten Version: https://forums.alliedmods.net/…hp?p=2730840&postcount=76
Vorneweg erstmal, ich bin noch lange kein Experte. Ich habe mich jetzt ein paar Stunden eingelesen, mir die Sprache (SourcePawn) grob angeschaut und versucht das Anti Team Flash Plugin zu verstehen.
Es gibt noch zwei weitere passende Plugins, die ich gefunden habe (eins sogar von 2017), die ich mir aber bis jetzt nicht näher angeschaut habe.
[CS:S] Anti Flash v1.2 - AlliedModders
[CS:S/CS:GO] Anti Team Flash - AlliedModders
Es kann durchaus sein, dass sich irgendwo im Code noch Typos, Leichtsinnsfehler/Syntaxfehler oder vielleicht sogar Logikfehler befinden. Vielleicht habe ich etwas auch falsch initialisiert oder nicht freigegeben. Getestet ist noch gar nichts, hab das jetzt nur mal so runtergetippt. Bin mit der Lösung auch nicht ganz zufrieden (die ganzen Timer...). Erschien mir jetzt auf den ersten Blick aber die einzige Möglichkeit zu sein, das irgendwie umzusetzen. Soweit ich gesehen habe, hat man nur das "player_blind" Event mit dem man arbeiten kann. Kenne DHooks/SDKHooks/SourceHooks nur vom Namen, vielleicht kann man sich mit diesen Plugins (mittlerweile Teil von SourceMod) ja an einer besseren Stelle einhaken.
Bezüglich des Anti-Team-Flash Plugins. Benutzt ihr zufälligerweise folgendes Plugin oder habt ihr euer eigenes geschrieben?
Hallo zusammen,
ich finde, dass die Hit Detection/Registration auf eurem Schlachthof 1 Server zu wünschen übrig lässt. Die rates aller Spieler werden zwar jetzt forciert, aber es fühlt sich immer noch "hit or miss" (pun intended) an, was die Hit Detection angeht. Vor allem spürt man das, wenn der Server voll ist. Auch vom movement her fühlt es sich oft nicht ganz so flüssig an.
Wenn ich das damit vergleiche, wie es sich damals zu Hochzeiten auf dem [DIE] Noobs Server (den es nicht mehr gibt) gespielt hat, dann schneidet der Schlachthof nicht ganz so gut ab.
Das kann natürlich an mehreren Dingen gelegen haben.
Irgendwann kam SMAC (frisst CPU und Gott weiß was das sonst noch so treibt), die 100er Tickrate wurde entfernt und bin mir auch nicht mehr ganz sicher, ob die Spielerzahl erhöht wurde (von urspr. 24), aber ab da ging es mit der Hit Detection auf dem [DIE] Noobs Server auch irgendwie bergab.
Gut über die Spielerzahl will ich gar nicht diskutieren, aber vielleicht kann man das Thema 100er Tickrate erneut prüfen. Denn soweit ich mich erinnere gab es auf dem [DIE] Noobs Server keine Physik-Bugs, wie von zEro erwähnt. Verbuggte Smokes gab es natürlich auch und das wird auch solange noch bleiben, bis Valve das fixt (als für immer), aber ganz so extrem war dort das Problem mit den Smokes nicht, wie bei euch.
Thema SMAC, ich bin natürlich dafür, dass es bleibt, aber das was ich dazu gelesen habe, lässt sich per cvars auch etwas optimieren, um die Server CPU Last zu reduzieren.
Ich weiß ich schieß hier ein bisschen ins Leere und bin etwas widersprüchlich, da bspw. eine höhere Tickrate die CPU Last erhöht und ich auf der anderen Seite von CPU Last reduzieren spreche. Mein Anliegen ist einfach, dass man sich die Themen evtl. gesondert anschaut und prüft, ob es zu einer Verbesserung führt. Ich habe schon auf anderen Servern mit höherer Spielerzahl als bei euch, ein besseres Spielerlebnis gehabt. Meiner Meinung passt da irgendwo was nicht ganz.
PS: Zu Server cvar "sv_clockcorrection_msecs", die auch in das Thema reinspielt, habe ich bis jetzt keine Antwort bekommen.
PS 2: Das Thema mit den Flashes ist auch noch offen. Ich kenne die Spielvariablen nicht, die man per Source Mod erreichen/modifizieren kann, aber es muss doch den Status "flashed" pro Spieler oder etwas ähnliches geben. Ziel des Plugins ist es ja an erster Stelle, zu vermeiden von einem Teammate geflasht zu werden. Ich kenne euren Plugin Code natürlich nicht, aber so ganz kann ich das mit dem Entflashen nicht nachvollziehen. Außer vielleicht, falls ihr das "Geflashtwerden" gar nicht aktiv verhindert, sondern es direkt nach Geschehen wieder umkehrt. Aber gibt es denn keine Variable/Timer (was auch immer), die man prüfen könnte, ob jemand bereits geflasht ist (sollte ja nur durch einen Gegner passieren) und falls ja, dann nichts machen.
Was meint ihr dazu?
Gruß
PRESSIVE
Heute um genau 21:30 gingen die Pings hoch.
Ich hätte gesagt ein cl_interp_ratio von 1 oder 2 ist zulässig, d.h. die Zeit für 1-2 Ticks bei eurer Tickrate von 66. Also cl_interp 0.0152 (1/66 -> 15,2 ms) - cl_interp 0.0303 (2/66 -> 30,3 ms) anstelle der standardmäßigen 100 ms (cl_interp 0.1).
Gibts bezüglich cl_interp schon irgendwas Neues?
Ist bezüglich cl_interp schon etwas in der Mache? Das Thema mit den Flashes und Smokes ist auch noch offen.
Zu der cl_interp Thematik. Was bereits funktioniert, ist dass das cl_interp_ratio den Wert 0 oder 1 (und dazwischen?) haben muss. Das Problem ist aber, dass unabhängig von den Rates standardmäßig cl_interp auf "0.1" (100 ms) gesetzt ist. Und solange der Wert gesetzt ist, überschreibt er quasi die cl_interp_ratio Einstellung. Damit cl_interp_ration zum Tragen kommt, muss man erst cl_interp auf "0" stellen und dann entsprechend das cl_interp_ratio einstellen. Dann wird cl_interp anhand der eingestellten Rates gesetzt. Heißt bei einer 66er Tickrate (cl_updaterate "66") wären das dann ~15,2 ms (cl_interp "0.0152"). Da kommen wir aber schon zum nächsten Problem. Auch wenn cl_update_rate forciert wird, ist immer noch lokal der Standardwert (20) oder was zuvor eingestellt war, gespeichert und wird für die Lerp-Berechnung verwendet. Das heißt, das Niedrigste was sich dann über das cl_interp_ratio mit Standardwert cl_updaterate "20" einstellen ließe, wären 50 ms (cl_interp_ratio 1 / cl_updaterate 20 = cl_interp 0.5 -> 50ms).
Um das zu umgehen, müsste man cl_interp_ratio auf 0 einstellen/forcieren und cl_interp direkt forcieren. Eine bessere Lösung habe ich bis jetzt nicht gefunden.
Was das Forcieren der Rates angeht, bin ich mir auch immer noch nicht 100% sicher. Manche Leute sind unkillbar und es fühlt sich generell nicht viel besser an als zuvor. Im net_graph kann man durch niedrige Einstellungen weiterhin den Ping beeinflussen, könnte aber auch einfach an einer fehlerhaften lokalen Berechnung liegen. Das einzige Indiz, dass das Forcieren der Rates funktioniert, ist das im Scoreboard nicht mehr so viele 5er Latenzen zu sehen sind. Nur bei Leuten, die auch wirklich einen niedrigen Ping haben (so um die 35 ms). Vielleicht könnt ihr da von eurer Seite noch einen Rate Checker bauen, mit dem sich das von Serverseite überprüfen ließe.
Gruß und schönen Sonntag
PRESSIVE
Also was mir sonst noch aufgefallen ist, dass sich der Ping im net_graph ändert, wenn man cl_updaterate kleiner einstellt. Nicht aber, wie oben schon erwähnt, die Latenz im Scoreboard. Ob das was zu bedeuten hat keine Ahnung. Glauben tue ichs aber erst, wenn ich keine Lowrates mehr bei echten Spielern sehe.
Ist halt etwas schwieriger auf einem leeren Server mit Bots zu testen.
Soweit ich jetzt testen konnte, es ist mir nicht gelungen mit cl_updaterate und cl_cmdrate (z.B. Werte von 10 jeweils) meine Latenz im Scoreboard zu beeinflussen, wohingegen ich auf dem normalen Schlachthof eine stabile 5er Latenz hatte. Auch hat die Lerp Einstellung funktioniert und mich auf ein cl_interp_ratio von 1 oder 2 begrenzt, solange ich halt die cl_interp_ratio Einstellung benutzt hab. Sollte für die meisten reichen, aber lässt sich halt mit cl_interp immer noch umgehen.
Öhm scheinbar nicht, war auf dem normalen Schlachthof. Warum sagt man das nicht? Naja dann hab doch noch ein bisschen Hoffnung, dass es funktioniert.
Edit:
Ok ja, Zero hat geschrieben Schlachthof 2. Ich hab halt immer nur den einen Schlachthof im Kopf, weil der andere immer leer ist. Dachte es wird auf dem vollen getestet.
Werds morgen auf dem anderen mal testen.
ok ich nehms zurück, spielt sich grad wieder richtig bescheiden. Vielleicht gabs vorher einfach weniger Traffic. Und da ich nicht glaube, dass die Rates geforced werden, wirds wohl beim Lerp auch nicht klappen.
Was ist mit der Einstellung "sv_clockcorrection_msecs"? Die steht immer noch auf Standardwert 60.
Ich glaub ich muss mal mit ner frischen Standardconfig ran, so wie die meisten spielen. Bin mir nicht sicher. Was aber nicht geht ist cl_interp_ratio höher als 1 zu setzen, aber weiß nicht, ob die Begrenzung da vorher schon gegriffen hat.
Also es spielt sich zwar grad ein wenig besser (flüssiger), aber das muss nichts heißen. Und meinen Lerp (cl_interp) kann ich immer noch auf 500ms stellen und das merkt man am meisten, weiß nicht ob ihr das forciert. Aber geht ja nicht allgemein um Rates sondern, das jeder solche rates hat, dass der Lerp niedrig ist.
Zudem habe ich cl_updaterate auf 5 und cl_cmdrate auf 10 stehen und auch meinen Fakeping im Leaderboard. Weiß nicht, ob das möglich sein sollte, steht zwar dran es wird auf 66 forciert aber kA. Aber ich muss sagen, soweit ich mich erinnere, spielt es sich mit cl_updaterate von angeblich 5 deutlich besser, als das letzte mal, dass ich das ausprobiert habe.
Bezüglich Lerp, ich glaub das liegt an mir. Soweit ich mich erinnere habt ihr min_ratio auf 0 und max_ratio auf 1 und ich habe cl_interp_ratio bei mir auf 0 und stelle das über cl_interp ein. Heißt man kann es umgehen. Für die meisten die mit Standardwerten spielen sollte es aber so funktionieren wie gedacht. Muss das weiter beobachten, kann ich jetzt nicht direkt beantworten. Da ich aber wieder Leute durch die Gegend laggen sehen, lässt mich das etwas zweifeln.
Was genau hast du jetzt umgestellt bzw. welche Werte wurden denn jetzt forciert?
