Ist das normal das, wenn ich den Server schließe es nicht gespeichert wird?
Ja, das ist normal.
Kicken brauchst du die Spieler nicht, es reicht, wenn du OnPlayerDisconnect für alle Spieler aufrufst, bevor der Server beendet wird.
Ist das normal das, wenn ich den Server schließe es nicht gespeichert wird?
Ja, das ist normal.
Kicken brauchst du die Spieler nicht, es reicht, wenn du OnPlayerDisconnect für alle Spieler aufrufst, bevor der Server beendet wird.
P_fuel,P_oil = '%f','%f'
Zu
P_fuel = '%f', P_oil = '%f'
zum beispiel will ich in pawno 26/2 rechnen das ergebniss ist ja: 12,5
26/2 ist 13
Dennoch, zum Code, das kannst du einfach so machen:
new ergebnis = GetPVarInt(playerid,"Marihuanablatt")/2;
Die Nachkommastellen fallen einfach weg. Angenommen "Marihuanablatt" hat den Wert 11, dann ist das Ergebnis 5.
Unter normalen Bedingungen stimmt das ja auch, klar.
Aber hast du jetzt 100 Leute auf einem großen Server, viele Befehle und alle geben sie zur selben Sekunde einen Befehl ein, kann es passieren das aus 2 Millisekunden, plötzlich 200 werden...und dann reden wir hier schon von 1/5 Sekunde..NUR um den Befehl der ja die eigentliche CPU zieht zu finden.
Man muss natürlich immer auch vom maximalen Fall ausgehen, das ist klar, aber selbst in dem Fall, der mehr als unwahrscheinlich ist, müssten 10.000 Befehle implementiert sein und gleichzeitig müssten 100 Spieler in der gleichen Sekunde (eigentlich Zehntel-Sekunde, sonst verteilt sich die Last über die Sekunde und man merkt nichts) einen Befehl eingeben, der im ungünstigsten Fall ganz unten steht. Das wäre dann ein einmaliger Lag von 0,2 Sekunden. Das stimmt, ich wage aber zu behaupten, das wird niemals vorkommen und selbst wenn es vorkommen sollte, wäre dieser einmalige Lag zu verkraften, vor allem da er bei ocmd auch nicht viel geringer wäre (0,1 Sekunden) und zudem kaum wahrnehmbar wäre.
Ich kann soviel sagen, auf meinem Server waren häufig 70-100 Spieler drauf, dass aber alle in der gleichen Sekunde einen Befehl eingegeben haben, ist nie passiert, selbst wenn die Eingabe per GameText beworben wurde. Command Prozessor war übrigens dcmd (was im Grund ja strcmp ist) mit strcmp gemischt (war damals halt so, würde ich heute natürlich nicht mehr machen). Performanceprobleme hatten wir nie, und die Hardware war auch schlechter als heute
Natürlich ist das jetzt nicht die Welt...aber es muss halt auch nicht sein.
Absolut.
Ich würde strcmp auch nicht als "Commandprozessor" empfehlen, dass muss klar sein. Es ging mir nur um die Klarstellung der Performancethematik, und die spielt, unter normalen Bedingungen absolut keine Rolle.
Ja...hier reden aber hier nur von einem Vergleich.
Natürlich im Vergleich sieht das so aus.
Praktisch merkt das aber wie gesagt niemand.
Du kannst zwei völlig normale Server parallel auf zwei identischen Maschinen mit gleich vielen Spielern laufen lassen. Einmal mit strcmp Befehlen und einmal mit ocmd Befehlen.
An der Last wirst du keinen - absolut 0,0 - Unterschied merken. Der Unterschied ist so gering, dass er nur im Tausendfachen messbar ist.
Das wäre in etwa so, also würdest du beim 100 Meter Lauf 12 Sekunden laufen, dir dann ein Haar raus reißen, und dann denken, du wärst jetzt schneller, weil du leichter bist. Theoretisch ja, aber praktisch nicht messbar. Darum geht es. Dass ocmd praktischer ist steht nicht zur Debatte, lediglich die völlig falsche Interpretation der Performanceanalyse.
Das macht es ehrlich gesagt nicht besser.
Und wie gesagt, es reichen schon 500 Befehle aus, dass der Server erstmal paar Millisekunden alle Strings bearbeiten muss...
Nein, hab ich doch geschrieben, um die 10.000 Befehle für ein "paar Millisekunden" (zwei also mindestens).
10.000 Befehle: 2640 Mikrosekunden ~ 2,6 Millisekunden
Und selbst wenn es 100.000 Befehle sind. 26 Millisekunden merkt kein Mensch. Erst ab 200.000 Befehlen würde es theoretisch minimal merkbar werden. Allerdings - und das ist der springende Punkt - auch mit ocmd.
Zudem hat kein Server 200.000 Befehle implementiert.
Ich muss hier mal einlenken, das kann ich so nicht stehen lassen. @RFT hat absolut Recht.
Grundsätzlich vorab, ocmd (oder andere) ist natürlich komfortabler und schneller als strcmp, aber die Performance kann sicher kein Grund sein, strcmp nicht zu nutzen, da sich alle Systeme so marginal unterscheiden, dass es niemals jemand merken wird.
Auch wenn die "schönen" Grafiken etwas anderes vermuten lassen, das zeigt mir, wie schnell hier falsche Schlüsse gezogen werden.
Und dann kann der Server evtl schon mal hängen, wenn der alleine für einen Befehl 2 Sekunden oder so benötigt.
Das kann in keinem reellen Fall passieren.
Die gezeigte Grafik bezieht sich auf 1000 (!) Befehle. Das heißt, 1000 strcmp Befehle benötigen 264 Mikrosekunden.
Alleine schon hier sehen wir, dass dies im Prinzip nichts ist. Den Unterschied zwischen 21 und 264 Mikrosekunden kann kein Mensch merken. Und 1000 Befehle sind wohl nur bei wenigen Servern implementiert.
Um das Ganze anschaulicher zu machen.
Wenn 1000 Befehle 264 Mikrosekunden benötigen (laut Grafik), dann benötigen:
10.000 Befehle: 2640 Mikrosekunden ~ 2,6 Millisekunden
100.000 Befehle: 26 Millisekunden
1.000.000 Befehle 260 Millisekunden
10.000.000 Befehle: 2600 Millisekunden ~ 2,5 Sekunden
Das heißt, du müsstest 10 Millionen (!) Befehle implementieren, damit dein Server bei strcmp 2 Sekunden benötigt.
Dabei würde aber auch ocmd ca. 1,5 Sekunden benötigen (ist nicht in der Grafik, da aber kein Plugin, ähnlich der anderen).
Man muss ja dazu sagen, dass wenn du evtl 100 Befehle hast...und es der letzte Befehl ist...kann das schon wesentlich länger dauern...
Das macht einen wesentlichen Unterschied von gigantischen 0,00001 Sekunden, sprich ein hundertstel einer Millisekunde, 10 Mikrosekunden, gegenüber ocmd.
Damit wäre alles gesagt.
da der OnPlayerSpawn nicht eingefügt wurde
Vielen Dank für deine Rückmeldung, freut mich, dass dir das Tutorial gefällt.
Zu deiner Anmerkung, das habe ich bewusst nicht hinzugefügt, da jeder Server dies anders handhabt und auch nicht direkt zum Benutzer-System im Grundaufbau gehört.
auf welches Fahrzeug er geklickt hat, um so weitere Informationen zu übergeben.
In OnDialogResponse:new count;
for (new fV; fV < MAX_FVEHS; fV ++)
{
if (fVehicle[fV][vehFraktion] == PlayerInfo[playerid][pFraktion])
{
if (Vehicle[fVehicle[fV][vehID]][vehAbgeschleppt] == 1)
{
if(count == listitem)
{
//Fahrzeug fV wurde angeklickt.
break;
}
count++;
}
}
}
Muss ich überall noch die VirtuellenWelten auf 0 setzen
Ja, sonst sehen sich die Spieler danach nicht mehr.
Außerdem, und daher der Fehler, musst du zusätzlich beim jeweiligen Ausgang, die virtuelle Welt abfragen.
Beispiel:
else if(IsPlayerInRangeOfPoint(playerid,2.0,2495.9133,-1692.0834,1014.7422)) // Grove Street Ausgang
zu:
else if(IsPlayerInRangeOfPoint(playerid,2.0,2495.9133,-1692.0834,1014.7422) && GetPlayerVirtualWorld(playerid) == 1) // Grove Street Ausgang
soll ich das System wie Mr.Monat als "Enum" System schreiben ?
Das wäre natürlich schöner und gegebenenfalls dynamisch aufbaubar, bei den bisher drei Ein-/Ausgängen aber auch nicht wirklich notwendig. Je mehr es werden, desto besser wäre es.
Zumal man deine Szenarien auch durch eine 2. Variablen lösen könnte wie...er ist Gast oder er muss Angemeldet sein.
Nein, dann könnte der Gast ja alle Befehle nutzen, auch diese, bei denen man eingeloggt sein muss und nicht als Gast nutzen darf.
Das ist zwar eine nette Idee, aber mit ocmd, kaum bzw gar nicht realisierbar.
Woher soll man im Callback auch wissen, dass im Funktionsheader der Parameter auf true gesetzt wurde?!
Doch, das geht. Mit kleinen Anpassungen in der Include, lässt es sich umsetzen.
Folgende beiden Befehle im Gamemode:
ocmd@g:testcmd(playerid)
{
SendClientMessage(playerid,-1,"TestCMD ausgeführt.");
return 1;
}
ocmd:testcmd2(playerid)
{
Spieler[playerid][pLoggedIn] = 1;
SendClientMessage(playerid,-1,"TestCMD2 ausgeführt.");
return 1;
}
In der Include folgendes einbauen:
#define ocmd@g:%1(%2) forward ocmdg_%1(%2);\
public ocmdg_%1(%2) { return 1; } ocmd:%1(%2)
Sowie nach der Schleife in der Include bei OnPlayerCommandText:
if(funcidx(ocmdStr2)!=-1&&!CallLocalFunction("Z_BeforePlayerCommandText","dsd",playerid,cmdtext,1))return 1;
Wobei ocmdStr2 zuvor entsprechend dem ocmdStr gefüllt wird, nur mit "ocmdg_...".
Und das Callback im Gamemode:
forward Z_BeforePlayerCommandText(playerid,cmdtext[],check);
public Z_BeforePlayerCommandText(playerid,cmdtext[],check)
{
switch(check)
{
case 1:
{
if(!Spieler[playerid][pLoggedIn]) return SendClientMessage(playerid,0xFF0000FF,"Du bist nicht eingeloggt"), 0;
}
}
return 1;
}
Ergebnis nach Eingabe:
1. /testcmd
2. /testcmd2
3. /testcmd
Somit lässt sich über den Kopf von ocmd steuern, welche Abfragen gemacht werden sollen.
Natürlich lässt sich das im Code bei mehreren Abfragen auch noch dynamisch darstellen (nicht mit fester 1 im dritten Parameter, etc), darauf habe ich jetzt aber verzichtet. Der Code soll nur zeigen, dass es geht.
Das "@g" würde in dem Fall dann für "Gastausschluss" stehen, sprich dass man eingeloggt sein muss, um den Befehl nutzen zu können.
1. Wer nutzt dafür heute noch Befehle?
Als Alternative zu den Textdraws würde ich das immer aufnehmen, es kann durchaus sein, dass jemand ohne Maus spielt, nur mit Tastatur und Gamepad. Grundsätzlich waren das auch nur Beispiele. Es kann auch sein, dass Gäste auf dem Server erlaubt sind und einige Befehle nutzen dürfen. Da nimmt man keine 150 Ausnahmen auf.
2. Man kann dafür Ausnahmen einfügen, ich hoffe das ist dir bewusst. Nur weil man 3 Befehle verwenden mag, soll man also in allen anderen 1000 diese Zeile Code nutzen?! aha.
Ich hoffe dir ist bewusst, dass ich auch nicht ganz blöd bin. Natürlich kann man Ausnahmen dort einbauen, aber warum sollte man das machen, wenn man es auch besser machen kann? Ich dachte darum ging es hier. Zudem habe ich nirgends behauptet, dass man die Zeile Code 1000fach nutzen sollte. Ach, ich vergaß...konstrukive Diskussionen sind nicht möglich.
Deshalb, und da ich auch keine Zeit und Lust habe, nehme ich den Rest vom Thread nicht weiter auseinander.
Wie dem auch sei, ich würde sowas über einen zusätzlichen Parameter im ocmd Kopf umsetzen. Das braucht keine Zeile Code, kann pro Befehl gesteuert werden, und benötigt keine Ausnahmen in dem Callback, die im schlimmsten Fall auch noch mit strcmp gemacht werden, und womöglich auch vergessen werden, was ein Notfall Update nach sich zieht. Den zugehörigen Code baut man dann in das Callback ein oder direkt in die Include.
Aber was weiß ich schon
Zu diesem Callback:
Und ich denke mir...wieso?! Wieso macht man sich die Mühe, das immer wieder zu schreiben.
So, dann hat man es einmal geschrieben und es gilt für alle Befehle.
Damit hast du dann auch den /register und /login Befehl deaktiviert, man könnte sich daher nicht mehr einloggen bzw. registrieren, ohne eingeloggt zu sein.
Ebenso Befehle wie /help oder /contact. Diese sollten durchaus ohne Login möglich sein. Daher macht es meiner Meinung nach keinen Sinn, dieses Callback für diesen Zweck zu nutzen, da der eine oder andere Befehl mehr, weniger oder andere Abfragen benötigt.
Poste bitte den Code dazu, sonst ist das Problem nicht nachvollziehbar.
Das ist doch jetzt ein ganz anderer Code. Wie stehen diese in Verbindung miteinander?
Funktioniert nicht wirklich .
Nutze mysql_query anstatt mysql_pquery. Empfohlen ist das aber nicht, auf Grund der Performance.
Außerdem
return dbname[MAX_PLAYER_NAME], 1;
Zu
return dbname;
Das Problem ist, dass du die in der Datenbank an 18. Stelle befindliche Tankstelle mit dem Biz an der 21. Stelle verknüpfen willst.
Dann klappt das mit "i" nicht (da das nur bis 18 bei den Tankstellen geht), sondern du musst die "id" nehmen und damit auch auf das Array zugreifen. Dort kannst du dann die 18. Tankstelle (mit der ID 21) mit dem 21. Biz (mit der ID 21) verknüpfen.
"id" hat in dem Fall dann den Wert 20, da die Indizes von Arrays ja bei 0 beginnen, daher wird id vorher um eine Stelle verkleinert.
Ok, jetzt verstehe ich das.
Ändere
cache_get_value_name_int(i, "id", tInfo[i][id_x]);
zu:
cache_get_value_name_int(i, "id", id);
tInfo[id-1][id_x] = id;
id--;
Und in dem public alle
tInfo[i]
zu:
tInfo[id]
sowie
bInfo[i]
zu:
bInfo[id]
und
tankLabel[i]
zu
tankLabel[id]
Es sind alle 18 Tankstellen geladen worden?
Hast du die Zeile entfernt?
Wenn ja, poste bitte den Server Log mit den prints.