Werte die mit < > umrundet sind, zählen als Platzhalter für deine Werte. Du musst also deine Werte entsprechend eintragen. Auch erwartet callExtension einen String. Bedeutet du musst dir den String entsprechend zusammenbauen.
Auch musst du das Protokoll und den Querynamen vorher festlegen. Ich habe dort nur Werte eingetragen die sinnvoll sind. Die aber nicht zwingend deinen Werten entsprechen.
Der richtige Syntax von callExtension ist folgender: "<EXTENSION>" callExtension <PARAMETER>
So zum Beispiel bei extDB3: "extDB3" callExtension "CALL_TYPE:PROTOCOL_NAME:DATA"
Doku extDB3 -> https://github.com/SteezCram/extDB3/wiki
Du möchtest am Schluss etwas haben wie sowas: "extDB3" callExtension "0:sql:updatePlayerTime:[<playerUID>, <time>]"
Wie Blackfisch schon geschrieben hat, ist die forEach-Schleife fehlerhaft.
Hast du die Variable "playerList" irgendwo definiert die du in deiner forEach-Schleife verwenden möchtest? Denn ansonsten wird es ebenfalls einen Fehler werfen.
Wie es im zweiten Code auch macht.
Im ersten Code bezieht sich der Fehler auf Zeile 4.
Die Zeile sieht so aus: [_result, _error] = callExtension "extDB3";
Du versuchst den Returnwert von callExtension in einem Array zuspeichern. Das klappt natürlich nicht. Du kannst es nur in einer Variable speichern.
Auch ist die Frage, was du mit Zeile 5 im ersten Code erreichen möchtest. -> "PlayerUID", playerUID, playtime;
Auch Zeile 20 vom ersten Code ist sehr interessant. Keine Ahnung was du da machen möchtest. -> updatePlayerPlaytimeInDB playerUID playtime;
Wie felixsch angemerkt hat, hat dein Code nicht soviel mit SQF zutun. Du solltest dir daher den Syntax von SQF nochmal anschauen. 
Für die Speicherung der Werte sehe ich zwei Varianten. Die erste ist die von dir angesprochene Datenbank über extDB. Die andere Variante ist, die Werte im profileNamespace zu speichern. Dabei werden die Werte in der "Profile.vars.Arma3Profile" abgelegt (wie es auch Antistasi macht). Inzwischen gibt es auch einen missionProfileNamespace, der die Werte nur für die Mission speichert (funktioniert ansonsten genauso wie profileNamespace).
Ich würde mich vermutlich für einen der beiden Namespaces entscheiden, da ich die Datenbank dafür als overkill empfinde (und um nicht getrennte Speicherorte zu haben).
Wie weit die Funktion genutzt werden kann ist mir nicht bekannt. Allerdings ist so eine Funktion auch schnell selbst geschrieben.
Dazu werden entsprechende Funktionen/EventHandler benötigt (wie initPlayerServer und handleDisconnect), die beim Connect und Disconnect etwas ausführen.
Die UID und die gespielte Zeit zu speichern reicht vollkommen aus. Die Zeit beim login kann als Variable auf dem Spieler gespeichert werden und ist somit jederzeit abrufbar.
Am einfachsten wird sein beim Betreten und Verlassen des Servers die Zeiten auszulesen. Die Differenz ist die "Spielzeit"
Wenn der Spieler die gewünschte Zeit x überschritten hat, wird etwas ausgeführt.
Da so der Spieler nur beim verbinden/trennen zum Member hinzugefügt wird, kann man auch alle x Minuten die Zeit addieren und prüfen ob die Zeit erreicht wurde.
Problem wird immer sein ob der Spieler auch wirklich gespielt hat und nicht einfach AFK war.
Dazu kann man auch ein Script erstellen, das prüft wie oft Eingaben getätigt werden. Das wird aber bisschen komplizierter und lässt sich zudem "austricksen".
Ich habe es mir angeschaut und konnte keinen Fehler erkennen. Daher habe ich es zum test auf einem meiner Server gestartet und ich erhalte sofort das Spawnmenü. Auch ist der Button "Respawn" im Menü vorhanden und funktioniert.
Daher gehe ich davon aus, dass du die Mission nicht als PBO gepackt hast.
Structured Text != String -> Siehe String
Einen Structured Text erhält man, indem man ihn mithilfe von parseText aus einem String parst.
Leider können wir aktuell nur raten. Denn auf meine Frage was zuletzt geändert wurde, bevor der Fehler auftauchte (wenn es davor funktioniert hat), kam keine Antwort.
Liegt vielleicht an <EVENT> <> sind im String Steuerbefehle, vielleicht wird Arma dadurch verwirrt.
Daran liegt es nicht, da das Problem schon davor auftritt.
Zusätzlich hat SQF keine "Steuerbefehle" in Strings.
Um das Problem mit der Verifizierung der Mod zubeheben, müsstest du nur den Key einfügen (im Keys Ordner).
Für das andere Problem habe ich die Log geprüft und kann nichts erkennen.
Bei der Log fehlt irgendwie auch die Hälfte (welche pbos geladen werden), zudem wäre die Clientlog (am besten Spiel starten, direkt versuchen und dann die Log senden) hilfreich.
Habe mir die Punkte angeschaut und würde sagen das es gut ausschaut. Allerdings ein paar kleine Änderungen:
6. Das Repository auf bitbucket wurde entfernt. Hier eine Kopie auf GitHub. -> https://github.com/SteezCram/extDB3
7. Kannst du weglassen. Denn .dll auf Linux. 
Um Arma als 32Bit zustarten, müsstest du nur die andere Datei auswählen.
32Bit -> arma3server
64Bit -> arma3server_x64
Wo das bei LGSM genau funktioniert kann ich aber nicht sagen, da ich mir eigene Systeme zum Server verwalten erstellt habe.
Grundsätzlich wird beim Wechsel von extDB2 auf extDB3 eigentlich nur die .so ausgetauscht.
Damit Arma auch auf extDB3 zugreift müssen die entsprechenden Angaben in SQF geändert werden.
Daher sehe ich aktuell keinen Grund, warum das Probleme machen sollte.
Alles klar. Nach ein bisschen suchen habe ich es gefunden.
Du startest den Server mit 64Bit.
extDB2 gibt es nur als 32Bit.
Also gibt es nun zwei Varianten.
1. Den Server mit 32Bit starten.
2. extDB3 einfügen, denn das gibt es als 64Bit.
Ohne den Inhalt der Datei zu kennen, kann man natürlich nicht sagen wo das Problem ist.
Allerdings wirst du wohl etwas verändert haben und dort hat sich ein kleiner Fehler eingeschlichen.
Oder ist deine script_macros im orginal Zustand?
Wenn dies der Fall ist, was hast du geändert bis es nicht mehr funktioniert hat?
Hat die extDB2.so execute Rechte?
Du liegst richtig. Das Problem liegt in der script_macros.hpp
Je nach Schwierigkeitseinstellung wird diese Anzeige entfernt. Wenn du eine andere Einstellung wählst, sollte die Anzeige wieder auftauchen.
Leider verstehe ich weiterhin nicht was du damit Ausdrücken möchtest.
Was haben nicht unterstützte Funktionen von Arma 3 mit Verschlüsselung zutun?
Abgesehen davon, welche Funktionen soll Arma 3 nicht unterstützt haben und inwiefern stellte dies ein Problem für die Performance dar?
Die Bilder sehen interessant aus.
Ich hatte mir eine Gesamtübersicht der Karte erhofft, denn die könnte ich bisher nicht finden (vielleicht bin ich auch blind :D).
Ich verstehe jetzt nicht was mit "zu heftig verschlüsselt für Arma3" gemeint ist. Kannst du das erklären?
Auch hätte ich mich über Bilder der Karte gefreut. Anhand von Bildern ist es nicht möglich die Karte selber zunutzen. Daher verstehe ich die Zurückhaltung nicht.
Also geht es dir nicht um bestimmte IPs, sondern um IP-Ranges. Die Info hat anfangs gefehlt.
Du kannst einstellen, dass allgemein nur diese IP-Ranges das System kontaktieren dürfen (System ≠ Arma3-Server).
Wenn man allerdings einen VPN-Dienst nutzt, kann man sich trotzdem verbinden. Somit ist dies kein wirksamer "Schutz".
Wer vorhat Unsinn zumachen wird vermutlich sowieso einen VPN-Dienst nutzen.
Du müsstest ein VPN erstellen und den Server nur dafür freigeben.
Ich frage mich zwar, wofür du das genau möchtest. Sehe andere Varianten als einfacher und sinnvoller an.
So kann man ein Passwort setzen und nur die Leute können dann auf den Server verbinden, oder du erstellst eine Whitelist für bestimmte UIDs.
