Das kann man pauschal nicht sagen. Du kannst den Server mit einer Zeile überlasten, oder mit 1000 Zeilen keine Probleme haben. Generell kommt es darauf an wie oft du den Timer aufrufst. Aber wenn es nur ein paar Berechnungen sind, die Textdraws updaten, macht das nichts aus.
ich epfehle einen settimerex für jeden Speieler da sich so der gesammte Code vertielt. dann nciht unbedingt glatt 5min nehmen sondern die nächste Primzahl.
Erklären kann man es wie folgt der Server hat 2 Phasen eine Script. (Hausaufgaben) und eine Syncrophase (Freizeit). kommt die Syncrophase zu kurz kommt es zu laggs.
Mit den Code den du momentan hast kannst du es wie folgt sehen. Jeder Spieler eist eine Hausaufagbe die der Sever aufbekommt. Wenn nun 10 Spieler drauf sind muss der Server laut deinen Code erst alle 10 Hausaufgaben machen und hat dann "Freizeit" in der er die Syncro übernimmt. Also wird dein Server mit zunehmender Spielerzahl belastet.
Machst du jetzt für jeden Spieler einen eigene Timer so hat der Server zwichen jeder Hausaufgabe ein wenig Freizeit.
und dann kommen die Bots wieder zum gebrauch.
Generell kann man gegen afk suchtis nichts machen.
per Pos: ein Bot machen, wo man Jede minute ein Schritt macht und alle 10min. sich um dreht.
per OnPlayerUpdate: einfach nicht auf dem Desktop gehen.
und bei beiden zusammen einfach(per Pos)
ich epfehle einen settimerex für jeden Speieler da sich so der gesammte Code vertielt. dann nciht unbedingt glatt 5min nehmen sondern die nächste Primzahl.
Also so in etwa?
1. Positions-Check
2. Nicht bewegt = SetTimerEx (nach 3min AFK), Bewegt = return 1;
Im Fall, dass er sich nicht bewegt hat...
3. 3min Timer endet damit, dass der Spieler AFK gesetzt wird.
4. 60min Timer wird direkt im Anschluss gestartet.
Ich bin davon ausgegangen, dass ich so viele Timer möglichst vermeiden sollte. Woran muss ich jetzt sparen? SetTimer oder SetTimerEx?
Auch dafür gibt es keinen Masterplan. Zu viele Prozeduren bedeuten ggf Überlastung, zu viel Auftrag in einer Prozedur kann zum selben Ergebnis führen.
Es muss halt immer drauf geachtet werden, wie oft und wie viel im Timer vorkommt. Wenn du panische Angst vor Lags hast, kannst du dein Problem z.B. auch über threaded SQL-Queries auffangen.
Letztlich muss man sich allerdings wegen solcher Kleinigkeiten erstmal nicht selber den Hals umdrehen. Oftmals wird das Wort "Timer" hier auch viel zu sehr dramatisiert.
generell gilt für Timer (so handhabe ich es):
kleinere Berechnungen und checks können in einem Timer gemacht werden größere Berechnungen Checks sollten mit mehreren Timer Ex gemacht werden.
Zum Thema wiederaufrufzeit: so klein wie nötig, so groß wie möglich. Zudem nehme ich gerne Primzahlen.
ich habe beispielsweise für meinen DayZ Server für den Schreibmaschinen Text beim Tutorial immer einen Playerbezogenen Timer von 3ms gemacht und dort einen kleinen Code ausführen lassen ohne Schleifen oder ähnliches dafür mit Zwichenspeichern von Variablen. Das ganze lief auch bei 40 Playern Laag frei. Es kommt immer darauf an was man genau macht. ein Timer mit einem kleinen Code der alle 30ms ausgeführt wird ist oft nicht so schlimm wie ein Timer der jede sekunde ausgeführt wird und eine 5000er Schleife mit ressourcenlastiger Berechnung.
Und da schließt sich wieder der Kreis. 
Kann man pauschal sagen, was "kleinere" und "größere" Berechnungen sind?
Ja, Primzahlen machen ja Sinn, weil es keine Überschneidungen mit den Berechnungen anderer Timer geben kann, da hast du recht.
Kann man pauschal sagen, was "kleinere" und "größere" Berechnungen sind?
Dateiabfragen (öffnen und schließen) würde ich nicht in einen Timer packen, außer er wird nur sehr wenig aufgerufen. Ebenso MySQL.
Generell:
Alles Spiel-Interne = kleine Berechnungen (außer du übertreibst es mit Loops) (Textdraws, Nachrichten, irgendwelche Get/Set Funktionen)
Alles Spiel-Externe = größere Berechnungen (Files, MySQL, ...)
Ebenso MySQL.
Bei SQL ist es nur relevant, wenn eine Antwort erwartet wird.
Bei SQL ist es nur relevant, wenn eine Antwort erwartet wird.
Auch Update Funktionen können zu massiven Lags führen.
Auch Update Funktionen können zu massiven Lags führen.
Nope, sobald der Query raus ist, macht der Server weiter, egal was passiert. Selbst wenn SQL dann was zu meckern hat, ist es dem Server egal, der ist mit der Sache fertig. Seit den threaded Queries sind sogar Queries mit erwarteter Antwort nur noch halb so wild.
Manyula: Mal als abstraktes Beispiel:
Du hast einen Timer, der 3 Sekunden Berechnungszeit pro Spieler hat. Setzt du das in eine Schleife für alle Spieler, hast du also Spieler * 3 Sekunden. Bei 12 Spielern währen also 36 Sekunden (nur um mal deutlich zu übertreiben) Lag vorhanden.
Wenn du diese Funktion nun auf jeden Spieler (SetTimerEx) aufteilst, hat der Server 3 Sekunden Lag, kann wieder was anderes abarbeiten, lagged wieder 3 Sekunden, hat wieder Zeit für was anderes, etc, etc..
dann sollte man auch vermeiden mehrere SetTimerEx für einen Spieler parallel laufen zu lassen
Das Problem ist dass die Timer von SAMP unglaublich ineffizient und sehr sehr ungenau sind.
Viele Timer heißen auch eine große Last für den Server.
Aber es gibt zum Glück ein paar Plugins (bspw. fixes2 von Y_Less) die dem entgegen wirken
Jeffry: Das wage ich zu bezweifeln. Denn der Query wird abgeschickt -> Server kann weiter arbeiten.
Nope, sobald der Query raus ist, macht der Server weiter, egal was passiert.
Ich würde es nicht sagen, wenn ich es nicht selbst getestet hätte.
...und nein, es waren keine tausend Queries, es war genau eins.
Manyula: Es ist besser einen Timer mit 50 Berechnungen zu haben, als 50 Timer mit je einer Berechnung, das geht weniger auf die CPU.
Ich würde es nicht sagen, wenn ich es nicht selbst getestet hätte.
Die Funktion wird ans Plugin übergeben, welches selbst in einem eigenen Thread hängt.
Also den test will ist sehen der das gegenteil beweist - denn rein SA:MP Teschnisch ist das schon eine Lüge.
Probleme bereiten eher sachen wie "store_result" weil die auf den Thread warten
