SQF-Handbuch

    Hallo James,


    Ich habe mir dein SQF-Guide mal angeguckt und etwas drinne gelesen. Ich muss sagen es sieht ziemlich übersichtlich aus und ist zudem auch ordentlich erklärt.
    Ich als Script-Anfänger werde dieses Buch mal intensiver unter die Lupe nehmen.


    Wenn ich mit diesem Guide fertig bin werde ich wahrscheinlich nochmal hier was Posten.


    Gute Arbeit!


    Gruß,
    Dustin

    Ich gestehe gleich, dass ich mir nicht alles angesehen habe. Ich möchte an der Stelle, dennoch positiv zu dem Guide beitragen.


    Was mir aufgefallen ist, was ich auch schon in vielen anderen scripts gesehen habe ist folgendes:
    Seite 104
    bordfunk.sqf
    Zeile 18
    sleep 1;


    Ich gestehe, dass ich keine Ahnung habe wie genau ACRE funktioniert.
    Bei TFAR habe ich bei mir selbst beobachten können, dass es relativ häufig vorkommt, dass es länger braucht, das Funkgerät zu ersetzen. Gerade bei Missionsbeginn, wenn alle möglichen scripts ausgeführt werden
    Von daher würde ich an der Stelle lieber ein WaitUntil-Lösung sehen.
    Mir ist auch klar, dass diese relativ aufwendig ist, dafür wesentlich robuster.
    Aber schließlich geht es ja darum, Wissen zu vermitteln und nicht möglichst schnell eine einigermaßen praktikable Lösung zu schaffen.
    Ebenso würde ich auf Seite 62 den Verweis auf sleep komplett streichen.
    Ebenso gibt es diese Magic-Sleeps an diversen anderen Stellen z.B. Seite 93 Zeile 8
    Ich bin einfach überhaupt kein Freund von so etwas.
    Gerade wenn man bedenkt, dass sich die Umgebung des Scripts ändert (unterschiedlich schnelle Rechner, unterschiedliche Auslastung durch 3. Scripts)
    Nicht falsch verstehen! Sleeps haben ihre Berechtigung z.B. um Schleifen auszubremsen.


    Seite 79, vorletzte Zeile:
    "sleep 1 oder sleep 0.5" durch "sleep 1 oder sleep 2" ersetzen, damit der Zusammenhang korrekt ist



    Ja, ihr dürft mich jetzt den "SleepHater" nennen ;)



    Im Kapitel "Vorzeitiges Beenden von Schleifen und Skripten" bitte darauf Hinweisen breakTo zu vermeiden.
    Fehlerbehandlung geht damit sehr schön, falsch angewendet führt es jedoch zu maxmal unleserlichem Code.



    Schöne Einführung!
    Da steckt sicherlich eine Menge arbeit drinnen!
    Ich freu mich schon auf das Multiplayer Kapitel, das linke ich dann direkt jemandem aus dem Clan :D

    Danke Coding für die sehr brauchbaren Vorschläge, werde ich bei einer Revision berücksichtigen. Die von dir angesprochenen Parts stammen aber alle aus Teil 3 und dort aus Projektvorstellungen. Dort stammt der Code also aus realen lauffähigen Projekten, bei denen man nicht immer jede Zeile prüfen oder anpassen kann, weil es manchmal auf einfach um reale Skripte geht - wie du schon sagtest, sowas kommt hier und da vor ;) Manchmal ist ein waitUntil unnötiger Balast, wenn ein sleep von 1 Sekunde in jedem Fall das Problem löst, manchmal eben unsauber. Bei meinen Skripten wende ich soetwas auch nicht mehr an, von daher muss man einfach schauen, wie diesbezüglich der Kontext ist und ob es sich lohnt, das abzuändern oder ob man es einfach nur diskutiert, um es eben auch mal aufzuzeigen.


    EDIT: Wenn das übrigens die einzige Kritim am Guide ist, dass überflüssige sleep-Befehle enthalten sind, ist das für mich nen großes Kompliment haha!

    Ja, das kenn ich... So ein sleep ist halt sehr schnell geschrieben :P
    Eventuell ist die Diskussion mit dem sleep/waitUntil sogar besser, als das simple "nutz das, und das nicht"
    Gerade in Verbindung mit einem Beispiel, das in vielen Fällen nicht klappt.


    Wie gesagt, insgesamt schöne Einführung.


    Was ich gerade noch sehe:
    Listing_35.sqf
    nicht vergessen
    private["_a","_b"];

    Mich stört an der Guide die Benennung der Variablen im Allgemeinen. Warum haben die deutsche Namen? Und warum haben die globalen Variablen keinen Tag? Nicht bös gemeint, aber das ist richtig furchtbarer Stil.


    breakTo/Out und scopeName könnte man komplett weglassen. Das ist genauso unnötig wie try-throw-catch und das wird ja auch nicht erklärt.

    breakTo/Out kann man nicht komplett weglassen und ist auch nicht unnötig, es sind einfach Features der Sprache, die ich selbst schon gebraucht habe, vor allem bei verschachtelten Schleifen. Hier sind sie absolut essentiell und eine wunderbar saubere Notation. Ob man das möchte, ist jedem selbst überlassen. try-throw-catch gab es damals noch nicht und wird es auch nicht geben, da es keine richtige Fehlerbehandlung ist, wie man es aus jeder anderen Programmiersprache kennt.


    Das mit den Namen mag sein, hängt aber SEHR vom Projekt ab, es gibt nicht ohne Grund eine ganze Seite zum Thema Benennung und Stil. Inzwischen würde ich auch nur noch englische Variablen benutzen aber...was solls? Dich stören die deutschen Namen? Dann nutz englische! Seit wann ist es furchtbarer Stil, in einem Werk auf deutsch für deutschsprachige auch deutsche Variablen zu benutzen? Also sorry, wenn das jetzt ein Argument für die Qualität ist, tuts mir leid. Stil entscheidet sich nicht an der Sprache, sondern daran, ob die Variablen sprechende Namen besitzen, sinnvol gewählt sind usw. Ob man jetzt Kommentare und Variablennamen in De oder En schreibt, ist bitteschön jedem selbst überlassen, so lange man nicht vorhat seinen Code zu veröffentlichen oder mit anderen zusammenzuarbeiten. Und selbst dann...wenn man sowas vor hat, wird es selbstverständlich sein, Englisch zu wählen. Und dass die globalen Variablen keinen TAG haben, ist genauso einfach: Kann man machen, wenn man in einem Projekt arbeitet und dann wird es entsprechend vorgegeben (siehe ACE Coding Standards) und falls ich dazu keine ANmerkung gemacht habe, werde ich das natürlich nachtragen, danke also für den Hinweis, aber es ist ansonsten für den Guide nicht weiter relevant ,vor allem nicht im ersten Teil, wo es um die Grundlagen von SQF und die Syntax geht. Wenn du deinen eigenen Guide schreibst und ihn teilen möchtest, kannst du gerne deine eigenen Konventionen benutzen, aber wirf anderen Leuten nicht vor, wie furchtbar ihr Stil ist. Denn es ist nunmal in der Definition des Wortes enthalten, dass dies eine subjektive Sicht ist. Und ob ich jetzt in einem Code _car oder _auto schreibe sollte niemandem vorgeworfen werden. Einzige Argument für Englisch ist nach meiner Sicht, dass eben alle Befehle in SQF englisch sind (was z.B. in Excel nicht der FAll ist ;)), weshalb es sich "natürlicher" liest und ich es wohl auch so umsetzen werde. Dennoch werden Kommentare aufgrund der Zielgruppe z.B. immer deutsch bleiben, solange es sich um Beispiele für den Guide handelt.


    Würde mir doch wünschen, ab und zu etwas "gehaltvollere" Kritik zu bekommen als solche Nichtigkeiten


    Ihr müsst euch endlich mal davon lösen, dass alle "euren" Stil befolgen müssen und es so sein muss, wie ihr das gewohnt seid. Das ist vor allem beim Lernen auch nicht immer förderlich, wenn man in dieser Haltung unterrichtet. Der Lerner sollte gerade feststellen, dass es viele Meinungen zu einem Thema gibt und sich selbst damit auseinandersetzen, um dann entsprechend seine eigenen Schlüsse zu ziehen. In diesem Sinne werde ich in meinem Guide am Anfang auf diese Thematik eingehen und gründlich über verschiedene Sichtweisen oder Richtlinien in Bezug auf Benennung usw. eingehen, aber letztendlich ist der Rest dann MEIN Stil und der sollte nicht kopiert werden, sondern jeder sollte seinen Stil in einem vernünftigen Rahmen entwickeln. Wie gesagt, die Beispiele sind keine Skripte, wie ich sie veröffentlichen würde, machten für mich aber zum damaligen Zeitpunkt so Sinn, damit der Lesefluss im Text nicht durch die Namen im Skript unterbrochen wird. So oder so ist es aber eben mein Stil und der sollte von keinem Leser kopiert werden. Er sollte nur nachvollziehen können, warum ich mich dafür entschieden habe, aber jetzt zu behaupten, dass jemand schlechter SQF lernt oder ein schlechter Scripter wird, weil er Variablen auf deutsch kennengelernt hat....naja...lasse ich dann mal so stehen


    PS: Was tatsächlich schlechter Stil ist, ist jede Art von Mischmasch. Dessen habe ich mich schuldig gemacht, wie mir eben auffält, da gelobe ich Besserung. Man sollte seine entscheidung Treffen (De, En, Camel-Style) und diese dann konsequent umsetzen). Ich gelobe Besserung ;)

    James, ja im ersten Kapitel wären die Tags etwas over the top. Aber generell fände ich zumindest den Hinweis, dass man Tags nutzen KANN sehr hilfreich zusammen mit einer kurzen Erläuterung ~10 Zeilen, was man dadurch für Vorteile hat.
    Angefangen habe ich auch ohne Tag. Dann habe ich Tags benutzt und dann Tags mit ProjektTags -> CODI_BFT_


    Auf Seite 63 unten nochmal explizit darauf hinweisen, dass es zu fehlern kommt, falls in einem call sleep, uiSleep oder waitUntil aufgerufen wird

    Seite 28 Operatoren
    3-5-2 = -4 Kein guter Stil, da mehrdeutig. Wo ist das mehrdeutig? In der Mathematik wird meines Wissens immer Klammer vor Punkt vor Strich und von links nach rechts gerechnet.


    Frage zu dem Thema.
    Kann Arma Bitoperatoren die Vergleichsoperatoren "|" "&" sowie Shiftoperatoren "<<" ">>"? Im Wiki stehen diese nicht, allerdings wie aktuell sind dort die Einträge?


    Seite 49
    ";:"? Für was wird der Doppelpunkt hinter dem Semikolon gebraucht? Rechtschreibfehler oder?


    Werde mir den Rest in Ruhe durchlesen.

    Coding: Ganz bei dir, ne Begründung sollte auf jeden Fall rein!


    Fabi: Es steht doch explizit da. Genau die Präzedenz ist hier die Frage und ich glaube nicht ,dass IRGENDJEMAND von uns in der Schule gelernt hat, welche Präzedenz das Minuszeichen hat. Demzufolge ist 3-5-2 für einen Leser ohne Wissen um die Präzedenz mehrdeutig, denn das Ergebnis ist je nach Assoziativität ein anderes, wie in der Tabelle aufgeführt wird. Also Guter Stil ist hier wohl das falsche Wort, da gebe ich dir recht, weil es eben unter der Haube eindeutige Regeln gibt, aber die Quintessenz für mich bei diesem Beispiel ist, dass die Absicht des AUTORS nicht zweifelsfrei hervorgeht. Möchte ich als Autor klarmachen, welche Var ich meine, lieber Klammern setzen. Aber das Beispiel ist aaarg künstlich, besser sind die oft zitierten Beispiele von (array select 0) select 1, wo auch ohne Klammern mal ausnahmsweise kein Fehler kommt, die Lesbarkeit aber m.E. stark leidet. Aber ich werde darüber nachdenken, dass Beispiel abzuändern, danke! Die Wortwahl "Stil" ist da definitiv falsch, da müsste eher sowas stehen wie "Mehrdeutige Lesart, aber eindeutig durch zugrundeliegende Definition" nur liest sich das net so schön *g*

    Ich finde die Benennung der Variablen in deutsch und ohne Tag furchtbar und finde es nicht gut, wenn Anfängern gleich etwas objektiv grundverkehrtes beigebracht wird. Tut mir leid, wenn du das nicht "gehaltvoll" findest, aber es erscheint mir zumindest elementar.


    Zitat von [3.JgKp]James

    try-throw-catch gab es damals noch nicht und wird es auch nicht geben, da es keine richtige Fehlerbehandlung ist, wie man es aus jeder anderen Programmiersprache kennt.

    Das kann irgendwie nicht richtig sein. try-throw-catch gibt es seit Arma v1.00. Nachzulesen auf dem BI wiki.


    Zitat von Coding

    Auf Seite 63 unten nochmal explizit darauf hinweisen, dass es zu fehlern kommt, falls in einem call sleep, uiSleep oder waitUntil aufgerufen wird

    Das stimmt so nicht. In "call"s kann man durchaus "(ui)sleep" und "waitUntil" benützen. Der einzige Unterschied zu "spawn" und "execVM" ist, dass "call" einen Rückgabewert gibt.
    Entscheidend ob man diese suspension-Befehle benützen kann ist einzig allein, ob man sich in der "normalen" oder der "scheduled environment" befindet. Das kann man mit "canSuspend" prüfen.
    Z.B. ist dieses "sleep" vollkommen legitim:

    CSS
    1. 0 spawn {
    2. call {
    3. sleep 10;
    4. hint "hello world";
    5. };
    6. };
    Zitat von jokoho482

    und seit 1.58 gibt es auch einen offiziellen command mit dem man das prüfen kann. https://community.bistudio.com/wiki/canSuspend
    wenn man vor 1.58 das testen wollte musste man eine for schleife 10001 mal laufen lassen und zählen wie oft sie aufgerufen wurde. wenn es 10000 mal war ist man im unscheduled environment und ansonsten im scheduled environment, da ArmA Maximal 10000 durchläufe in unscheduled environment um CTD durch SQF zu verhindern um halt kein Endloss loop zu bekommen in der SQF Engine

    ich wüsste nicht seit wann ein endloser loop einen CTD auslösen kann ... (wobei ... wer weiß schon wie die ArmA VM das memory handling genau macht ... vllt doch möglich)






    in bezug auf die "unwesentlichkeit" von try-catch weil es ja kein "echtes" try catch ist ...
    stimmt nicht ganz
    was stimmt: per default wird es nichts catchen was ein runtime error ist (eg: x / 0)
    das lässt sich jedoch ebenso hinzufügen mithilfe von assert:


    und schon wäre alles abgesichert was kommen kann

    Zitat von commy2

    Gib einach mal das hier in die Debug-Konsole ein:


    CSS
    1. _a = {call _a}; call _a

    CTD. "while {true} do {};" würde das gleiche machen, wenn es nicht nach 10000 Durchläufen aussteigen würde.

    der grund für den crash hier ist aber ein anderer
    zweiteres ist ein loop der eigentlich nicht crashen sollte
    ersteres wird auch in allen anderen programmen einen CTD ausführen bedingt dadurch, dass der stack irgendwann voll läuft

    @X39 es bleibt dabei, try catch absolut unwesentlich wie du selbst vorführst, weil die Überprüfung durch Rückgabewert true erfolgt. Damit try catch absolut sinnfrei und kann durch exitWith{} genauso beendet werden.


    @Admin: Könnte man den Thread etwas aufräumen und die Fachgespräche löschen oder ausschneiden? Mir hilft es hier überhaupt nicht weiter, wenn der Thread für Fachgespräche genutzt wird, die mit dem Thema nichts zu tun haben und ich weiß nicht wieso gerade hier ausgetragen werden, auch wenn sie interessant sein mögen. Gibt es hier überhaupt keine Guidelines oder Richtlinien, nach denen man sich hält? Seid mir nicht böse, aber das artet hier gerade extrem aus.


    Kleine Lister Posts, die ich ausschneiden würde: 50, 49, 48, 48, 46, 44, 43, 42, 41, 40, 39, 36, 28,27,26, 23, 22, 21


    Also wäre genug zum Aufräumen und ehe jemand meckert - sind auch Posts von mir dabei ;)

    es ist nicht sinnbefreit da es ein anderes ziel verfolgt
    die argumentation die du hier als "sinnbefreit" anwendest kann man in jeglichen anderen sprachen dann nämlich auch gegen try catch anbringen


    try catch ist so wie viele andere kontrollstrukturen schlich weg ein essentieller teil von ArmA und somit nicht "sinnbefreit" sondern wesentlich (zumindest sollten exceptions die vom nutzer geworfen werden angesprochen werden)

    Kurzes Update: Die aktuellen Ideen gehen weg von einer PDF und hin zu einer Online-Lernplattform, die dann auch direkt Möglichkeiten des Feedbacks etc. bietet. Code-Beispiele könnten dann life eingebunden werden. Der Leser hätte direkte Möglichkeiten durch Hyperlinks zu springen und Referenzen life zu nutzen. Außerdem würde ein Ticketsystem bzw ein Forum das Ganze interaktiv gestalten und Möglichkeiten der Bewertung wie Qualitätssicherung bieten. Werde das Projekt wahrscheinlich mit Drupal oder Derivaten umsetzen.


    => Folgerung: Zeitansatz ist gerade exorbitant angestiegen XD


    Damit hätte man aber auch die Möglichkeit, das ganze deutlich attraktiver für Skripter zu gestalten. So könnten Skripter eigene Skripts anbieten oder als Coautoren tätig werden, wie man es von einem CMS gewohnt ist. Wer einsteigen möchte, ab sofort akzeptiere ich Bewerbungen ;)

    Im Voraus sei bemerkt, dass ich dein Handbuch bisher nicht gelesen hab, dh im Falle meine Vorschläge schon inkludiert sind, kannst du meinen Post getrost ignorieren ;)


    • Ich denke es sollte eine Erwähnung rein, dass es eine gute Idee ist, am Ende jeder Funktion, die keinen RückgabeWert hat, nil zurück zu geben, da es sonst unter Umständen zu sehr komischen Fehlern kommen kann. (siehe diesen Post)
    • Eine Anmerkung, dass es während der Entwicklung eine tolle Sache ist, wenn man allowFunctionsRecompile = 1; in die description.ext rein packt, da man so Änderungen am Script vornehmen kann und dann in der laufenden Mission einfach nur auf "Recompile" drücken muss, anstatt die ganze Mission neu zu starten, damit die Änderungen übernommen werden (Gilt natürlich nur für Funktion aus CfgFunctions). Ich selbst habe das nämlich eben erst entdeckt (Und ich hab nicht erst gestern mit scripten angefangen)... ?(

    MFG Raven