Hallo Brotfische,
in diesem Tutorial will ich mal ein paar Tipps zum Thema Scripting geben.
Immer wieder fallen mir bestimmte Muster auf, die gerade bei etwas unerfahrenen Skriptern passieren.
Hier gehe ich nun mal ein wenig auf Fehlerquellen ein und versuche diese gut darzustellen.
1. Globale Strings
Also sowas sehe ich in letzter Zeit wieder relativ häufig.
//Oben im Skript:
new DialogString[4096];
CMD:1(..)
{
format(DialogString);
}
CMD:2(..)
{
format(DialogString);
}
Alles anzeigen
Das ist zwar eine "nette Idee", allerdings birgt das viele Risiken und ist nicht so dolle, da es zu Überschreibungen und somit zu Fehlern kommen kann.
Also einfach für jeden Dialog eine passende lokale String Variable erstellen.
2. Wiederholungen
Etwas, was man eigentlich als Programmierer unbedingt vermeiden will.
Denn je öfter man etwas neu bzw versucht gleich zu machen, desto höher die Wahrscheinlichkeit, dass Fehler auftreten.
Das ist auch eigentlich das Haupt-Anliegen von meinem Thread. Ich will euch ein wenig dafür sensibilisieren.
Wir schauen heute mal auf Commands, da sich hier wohl mit am Meisten wiederholt.
Viele verwenden ja einen "CMD-Prozessor", das ist schon mal sehr gut.
Nehmen wir mal ocmd.
Viele verstehen die Reihenfolge nicht.
Es gibt einen Callback: BeforePlayerCommandText dieser wird aufgerufen, bevor die ocmd:xxx(..); ausgeführt werden. Wenn man dort return 0; wiedergibt, dann werden diese auch nicht ausgeführt.
Besonders sowas sehe ich sehr oft:
ocmd:bla(playerid)
{
if(!Spieler[playerid][pLoggedIn]) return SCM(playerid,-1,"Du bist nicht eingeloggt");
}
ocmd:bla2(playerid)
{
if(!Spieler[playerid][pLoggedIn]) return SCM(playerid,-1,"Du bist nicht eingeloggt");
}
ocmd:bla3(playerid)
{
if(!Spieler[playerid][pLoggedIn]) return SCM(playerid,-1,"Du bist nicht eingeloggt");
}
Alles anzeigen
Und ich denke mir...wieso?! Wieso macht man sich die Mühe, das immer wieder zu schreiben.
public BeforePlayerCommandText(playerid,cmdtext[])
{
if(!Spieler[playerid][pLoggedIn])
{
SCM(playerid, -1,"Du bist nicht eingeloggt!");
return 0;
}
return 1;
}
So, dann hat man es einmal geschrieben und es gilt für alle Befehle.
Nun, kommen wir zu weiteren Dingen.
Viele glauben, dass es einen Performanz Verlust ergibt, wenn Sie anstatt SendClientMessage nur SCM schreiben, wenn es wie folgt definiert ist:
#define SCM SendClientMessage
Aber nur nochmal für alle, dem ist nicht so!
Das Makro wird durch den Pre-Compiler ersetzt beim kompilieren des Skriptes. Dadurch ergibt sich dadurch 0 Verlust, man spart sich lediglich viel schreiben.
Somit ist es sehr sinnvoll viele Abkürzungen zu haben (am Besten in einem eigenen Include, damit es übersichtlicher ist, nur Makros):
//Hier mal einige Beispiele zur Inspiration:
#define SCM SendClientMessage
#define SCMT SendClientMessageToAll
#define SPD ShowPlayerDialog
#define Freeze(%0) TogglePlayerControllable(%0,0)
#define UnFreeze(%0) TogglePlayerControllable(%0,1)
#define SetPos(%0,%1,%2,%3,%4) SetPlayerPos(%0,%1,%2,%3),SetPlayerFacingAngle(%0,%4)
#define SetWorld(%0,%1,%2) SetPlayerInterior(%0,%1),SetPlayerVirtualWorld(%0,%2)
Wie man sieht, kann man sich dann sehr viel Schreibarbeit schenken!
Schauen wir uns nun weiter
if(GetPlayerState(playerid) != PLAYER_STATE_DRIVER) return SendClientMessage(playerid, -1, "Du bist nicht der Fahrer eines Wagens!");if(!IsPlayerConnected(giveplayerid)) return SendClientMessage(playerid, -1, "Ein Spieler mit dieser ID ist nicht online!");
Also diese Statements kennt jeder und in fast jedem Befehl kommt so ein Statement bzw so eine Abfrage vor, die sich wiederholt.
Viele denken jetzt einfach, jo dann schreib ich das immer wieder und wieder hin.
Hier entstehen aber oftmals Rechtschreibfehler oder andere Fehler + es ist sehr Zeitaufwändig + eine Wiederholung.
Also auch hier ist es wieder sinnvoll, am Besten auch wieder in einer Include oder oben im Skript auslagern, vordefinierte Nachrichten zu machen.
Gerade bei so Fehlermeldungen ist dies sehr einfach.
In 100% der Fälle, werden diese nämlich immer an playerid geschickt, da das der Spieler ist, der den Befehl eingegeben hat.
Mit diesem Wissen, können wir nun folgendes machen:
//Mal wieder zur Inspiration ein paar:
#define NO_ADMIN SCM(playerid,rot,"Sie besitzen nicht die notwendigen Rechte, für diesen Befehl!")
#define NO_RANGE SCM(playerid,rot,"Dieser Spieler befindet sich nicht in Ihrer Nähe!")
#define NO_LEADER SCM(playerid,rot,"Sie sind kein Leader einer Fraktion!")
#define NO_CON SCM(playerid,rot,"Ein Spieler mit dieser ID oder mit diesem Namen ist nicht online!")
#define NO_YOU SCM(playerid,rot,"Diesen Befehl kannst du nicht auf dich selbst anwenden!")
#define NO_VEH SCM(playerid,rot,"Sie befinden sich in keinem Auto!")
#define NO_FRAK SCM(playerid,rot,"Sie befinden sich in keiner Fraktion!")
#define NO_COP SCM(playerid,rot,"Sie befinden sich in keiner Staatsfraktion!")
Und dann kann man einfach folgendes schreiben:
if(!IsPlayerConnected(giveplayerid)) return NO_CON;
NO_CON ist in dem Fall einfach nur die Abkürzung für NO_CONNECTION, also keine Verbindung.
Kann man natürlich alles wählen wie man will.
Viele werden jetzt sagen, jo, das kann man doch noch weiter vereinfachen, z.B.:
#define NO_CON(%0) if(!IsPlayerConnected(%0)) return SCM(playerid,rot,"Ein Spieler mit dieser ID oder mit diesem Namen ist nicht online!")
Verwendung wäre dann:
NO_CON(giveplayerid);
Ja, das wäre auch möglich, aber es würde die Code-Logik ein wenig zerstören, da man jetzt nicht mehr nachvollziehen kann was genau dieses Makro macht.
Man sieht keine if-Abfrage mehr usw.
Wenn man alleine an einem Skript arbeitet kann man das machen, aber sobald mehrere involviert werden, macht es das nur noch komplizierter.
Standardisierte Nachrichten hingegen, machen es noch einfacher, dass man nicht plötzlich von dem einen Command diesen und vom anderen diesen Wortlaut bekommt 
Noch ein Punkt sind wiederholende Funktionen.
Mal ein Beispiel, wir wollen rausbekommen, ob ein anderer Spieler in unserer Nähe ist.
Ohne Mist, ich habe das in so vielen Skripts gesehen, dass ich das dann alles immer 1:1 von Befehl zu Befehl wiederholt.
new Float:x,Float:y,Float:z;
GetPlayerPos(playerid,x,y,z);
if(!IsPlayerInRangeOfPoint(pID,5.0,x,y,z)) return NO_RANGE;
Das sind zwar nur 2 Zeilen zusätzlich, aber warum?
Sofort eine Funktion daraus machen und auslagern. Viele meinen jetzt sicherlich, joa ist doch eigentlich unnötig, die 2 Zeilen da.
stock InRange(playerid,pID,Float:r)
{
new Float:x,Float:y,Float:z;
GetPlayerPos(playerid,x,y,z);
return IsPlayerInRangeOfPoint(pID,r,x,y,z);
}
//Abfrage lautet dann eben nur:
if(!InRange(playerid,pID,5.0)) return NO_RANGE;
PS: Viele machen auch die geschweifte Klammer immer direkt hinter den Parametern, also stock InRange(playerid,pID,Float:r) { Das kann man machen, wenn man es übersichtlicher findet. Aber nur zum Verständnis, dies macht keinen Unterschied. Es spart weder Ressourcen, noch sonst etwas.
Es ist wichtig zu verstehen, dass es bei gutem Scripting bzw generell programmieren um die Übersichtlichkeit geht.
Okay, also wieso ist es jetzt gut, dass wir das ausgelagert haben?
Also zum einen ist klar, dass wenn wir das 50x brauchen, wir uns 100 Zeilen Schreibarbeit sparen 
Zum anderen ist es so, dass wenn uns jetzt auffällt, dass wir auch noch den Zustand überprüfen müssen von dem Spieler, bspw soll das natürlich nicht klappen, wenn der eine im Spectate Modus ist oder gerade spawnt.
Also deklarieren wir uns wieder eine Funktion:
stock IsValidState(p)
{
switch(GetPlayerState(p))
{
case PLAYER_STATE_WASTED,PLAYER_STATE_SPAWNED,PLAYER_STATE_SPECTATING: return 0;
}
return 1;
}
Und können das jetzt ganz einfach in unserer Funktion ergänzen und somit wird es für alle ergänzt.
stock InRange(playerid,pID,Float:r)
{
new Float:x,Float:y,Float:z;
GetPlayerPos(playerid,x,y,z);
return (IsValidState(playerid))?IsPlayerInRangeOfPoint(pID,r,x,y,z):0;
}
Denn es wäre sehr mühsam das überall zu ergänzen und wenn man es ausgelagert hat, ist es sehr einfach solche "Bugs" zu beheben
Selbiges gilt auch zum Beispiel für Schleifen für Admin-Nachrichten.
Sehe da immer wieder Leute die da sowas machen:
for(new i; i<MAX_PLAYERS; i++)
{
if(IsPlayerConnected(i) && IsPlayerAdmin(i))
{
SendClientMessage(i,-1,string);
}
}
Das wird dann immer und immer wieder kopiert oder selbst geschrieben unter alles mögliche gepackt.
Funktionen Leute, Funktionen.
stock SendAdminMessage(color, const msg[])
{
for(new i=GetPlayerPoolSize(); i!=-1; i--)
{
if(IsPlayerConnected(i) && IsPlayerAdmin(i)) SCM(i,color,msg);
}
return 1;
}
Dann kann man wieder hier ergänzen, wenn man Admin-Abfragen ändert o.ä. anstatt dann wieder durchs ganze Skript zu rennen.
Okay, hoffen wir mal, die Punkte sind jetzt klar und ich habe euch ein wenig dafür sensibilisiert.
3. switch oder if?
Da ich das gefühlt sehr sehr oft erwähnen muss und irgendwie viele auch nicht wissen hier nochmal eine kleine Erläuterung:
Kurz und knackig, sobald ihr überlegt switch oder if, dann immer switch wählen.
if-Abfragen haben den Nachteil, dass diese erst alle einzeln geprüft werden müssen. Wohingegen bei einem switch direkt dahin gesprungen wird.
Allerdings gibt es auch manchmal Bereiche, wo man weder if, noch switch verwenden sollte.
Schauen wir uns dazu mal ein Beispiel an.
Nehmen wir mal als Beispiel Admin-Rang-Namen.
/*
Vorab mal kurz etwas zur String-Zuweisung:
Viele nutzen dafür ja format, das ist auch richtig, aber nur dann, wenn wir nicht wissen, welche Größe der String den wir zuweisen hat.
Ansonsten können wir auch einfach eine direkte Zuweisung machen, die auch 1000x schneller ist :)
Direkte String-Zuweisung ist immer schneller als alles andere.
Mal einige Funktionen der Geschwindigkeit her sortiert:
Direkte Zuweisung - super schnell
stract - normal
strmid - sehr langsam
format - super langsam
*/
//if-Variante
//->schlechteste
stock GetAdminRangName(playerid)
{
new string[64];
if(Spieler[playerid][AdminRang] == 0) string = "User"; //Direkte Zuweisung
else if(Spieler[playerid][AdminRang] == 1) string = "Moderator";
//usw
return string;
}
Alles anzeigen
So, das ist viel Schreibarbeit und dann auch noch langsam 
Das sollte nicht unser Ziel sein.
Nehmen wir switch:
stock GetAdminRangName(playerid)
{
new string[64];
switch(Spieler[playerid][AdminRang])
{
case 0: string = "User"; //Direkte Zuweisung
case 1: string = "Moderator";
//usw
}
return string;
}
Alles anzeigen
Das ist schon um einiges besser und auch viel weniger Schreibarbeit.
Aber, da diese Dinge, ja immer konstant bleiben, können wir sie auslagern:
stock const admin_rang[][] = {"User","Moderator",...};
#define GetAdminRangName(%0) admin_rang[Spieler[%0][AdminRang]]
Dann brauchen wir auch nicht mal mehr eine Funktion, sondern können das direkt so nutzen.
Natürlich kann und sollte man nicht alles in den Heap Speicher auslagern (globale Variablen landen im Heap, lokale Variablen landen im Stack).
Allerdings kann man so ein array ja auch kurzfristig im Stack erstellen und dann abfragen.
So schenkt man sich meistens sehr viel Schreibarbeit
4. Variablen wiederverwenden
Was ich weiterhin oft sehe ist sowas hier:
new megaString[4096], kleinerString[256], kleinerString2[256], mittel[512];
Und dann verwendet man auf den kleinen format und packt mit strcat das alles in den mittelString.
Und dann den mittelString in dem megaString und das halt ein paar mal, bis alles im megaString ist.
Okay...kann man machen, allerdings reicht es hier nur den megaString zu haben, der meistens auch viel zu groß ist.
Also gehen wir als Erstes auf die Größe ein.
Man kann meistens abzählen, wie groß so ein String ist, na klar, keiner macht sich die Mühe, das auf das Zeichen genau zu zählen. Das ist auch nicht nötig es reichen gute Schätzungen.
Hier mal ein Beispiel:
new string[128];
format(string,sizeof(string),"Hallo %s!",GetName(playerid));
Das ist natürlich viel zu groß.
Es reicht hier einfach folgendes zu machen:
new string[10+MAX_PLAYER_NAME];
format(string,sizeof(string),"Hallo %s!",GetName(playerid));
Es ist nicht unperformant sowas zu tun, da solche Konstanten Additionen vom pre-compiler ausgerechnet werden und somit hat man eben am Ende dort einen festen Wert stehen.Also ist es sehr gut sowas zu verwenden, da dann weniger Speicher reserviert wird.
Aber jetzt zur Wiederverwendung:
new string[512];
format(string,sizeof(string),"Hallo du bist");
format(string,sizeof(string),"%s ein Idiot!",string);
So format leert auch gleichzeitig immer den String, deshalb ist es u.a. so langsam. Wir können also mit dem %s Trick den vorherigen String wieder dran hängen und können so Ketten bilden.
Dann brauchen wir weder andere strings, noch strcat.
Man kann übrigens auch direkte Zuweisungen bei der Deklaration machen:
new string[512] = "Hallo du bist";
format(string,sizeof(string),"%s ein Idiot!",string);
Und richtig, da wir hier keine Variable formatieren im format, sollten wir hier lieber strcat nutzen.
new string[512] = "Hallo du bist";
strcat(string,"ein Idiot!");
So mal ein bisschen zum Verständnis.
Schlusswort
Also erstmal, vielen Dank, dass du mein Tutorial bis hier hin gelesen hast
Man kann zusammenfassend sagen, dass man es vermeiden sollte, viele Dinge zu wiederholen und mit Tricks vieles einfacher schreiben kann.
Ich werde das hier mit der Zeit wahrscheinlich noch ein wenig anpassen und ergänzen.
Also wenn ihr weitere solcher Fehler kennt, schreibst einfach mal in den Thread, dann können wir ein wenig darüber reden
