Schneller & strukturierter skripten

Wichtiger Hinweis: Bitte ändert nicht manuell die Schriftfarbe auf schwarz sondern belasst es bei der Standardeinstellung. Somit tragt ihr dazu bei dass euer Text auch bei Verwendung unseren dunklen Forenstils noch lesbar ist!

Tipp: Ihr wollt längere Codeausschnitte oder Logfiles bereitstellen? Benutzt unseren eigenen PasteBin-Dienst Link
  • 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.


    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:


    Und ich denke mir...wieso?! Wieso macht man sich die Mühe, das immer wieder zu schreiben.


    C
    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):



    C
    //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:



    C
    //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.


    C
    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.



    C
    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:



    C
    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.




    C
    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:


    C
    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.


    C
    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.


    So, das ist viel Schreibarbeit und dann auch noch langsam :/


    Das sollte nicht unser Ziel sein.


    Nehmen wir switch:



    Das ist schon um einiges besser und auch viel weniger Schreibarbeit.
    Aber, da diese Dinge, ja immer konstant bleiben, können wir sie auslagern:


    C
    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:


    C
    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:


    C
    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:


    C
    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:


    C
    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:



    C
    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.




    C
    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 :)

    ast2ufdyxkb1.png


    Leute, lernt scripten und versucht mal lieber etwas selber zu schreiben, als es aus einem GF zu kopieren. :S

  • 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.


    Hier sollte noch beachtet werden, dass der BeforePlayerCommandText-Callback für ocmd noch aktiviert werden muss. Sonst wird der Callback von ocmd nicht aufgerufen.


    (Nachzulesen in den Pofi-Funktionen)

    Mit freundlichen Grüßen,
    hundi :thumbup:


    "Wuff!, Wuff!"
    hundi, 2017

  • 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.

  • 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.

    1. Wer nutzt dafür heute noch Befehle?


    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.

    ast2ufdyxkb1.png


    Leute, lernt scripten und versucht mal lieber etwas selber zu schreiben, als es aus einem GF zu kopieren. :S

  • 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 :fun:

  • konstrukive Diskussionen sind nicht möglich

    Hmm? Doch natürlich, kannst gerne schreiben, was dich stört, nur dann solltest du auch schon eine Alternative bieten und keine einfaches, ja das ist nicht gut.
    Zumal man deine Szenarien auch durch eine 2. Variablen lösen könnte wie...er ist Gast oder er muss Angemeldet sein.

    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.

    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?!


    Das müsste man dann zwischenspeichern und das wäre sehr aufwändig...da ist es einfach ein paar Ausnahmen zu schreiben oder das anders zu realisieren.
    Aber im Endeffekt ist das noch um einiges umständlicher und viel schwieriger.


    Mein Vorschläge sind einfach zu realisieren & zu integrieren.
    Klar könnte man direkt auch auf Plugins wie https://forum.sa-mp.com/showthread.php?t=608474 umsteigen, wo man schon eine größere Funktionalität geboten bekommt, aber darum ging es ja eigentlich nicht.

    ast2ufdyxkb1.png


    Leute, lernt scripten und versucht mal lieber etwas selber zu schreiben, als es aus einem GF zu kopieren. :S

  • 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.