Do you mean, that the civilian faction as default selected?
As far i know, there is no solution for this case. The first faction in the list is default selected.
Do you mean, that the civilian faction as default selected?
As far i know, there is no solution for this case. The first faction in the list is default selected.
Dann hat der verwendete Datenbanknutzer vielleicht nicht die ausreichenden Rechte um den Query auszuführen.
Prüfe die Rechte des Nutzers.
Auf die schnelle fällt mir keine Einstellungsmöglichkeit ein, die Arma mitbringt.
Man könnte eine Extension programmieren, die beim verbinden das Profil prüft.
Wobei ich mich eher frage, welchen Gedanken du damit verfolgst. Denn auf die Sicherheit hat es keinen Einfluss.
Hast du alle Configwertw und Dateien eingefügt?
Denn dann ist die Rückgabe von extdb3 im Code interessant.
Dazu einfach schauen welcher Wert in der fraglichen Variable gespeichert ist.
Anscheinend ist der Rückgabe Wert von extdb3 nicht wie erwartet.
Schau Mal welche Rückgabe dort kommt.
RPT Logs ?
Auch wenn er zwar schreibt, dass er Logs hochgeladen hat (was hier fast alle machen), aber keine angehängt hat (was auch fast alle machen und natürlich schlecht ist). Versucht er nach seiner Beschreibung einen Server mit steamcmd (?) zu installieren. Dabei werden keine RPT-Logs generiert.
Gebe bei dem Command nicht den Parameter -beta an.
Im Serverprofil kann man einstellen, ob deathMessages angezeigt werden sollen. Dieses deaktivieren und es sollte weg sein.
Natürlich auch das Profil laden.
hallo Henne ich habe schon mal auf linux arma3 server lauge gehapt habbe ich alles aus poiert
auf 32Bi leuft extDB3_x64.so nicht
Das ist ja auch selbstverständlich. Denn auf einem 32 Bit System benötigt man auch 32Bit Software.
ich habe dasauch ver such auf lunx ist für arma3 nicht gut ich beteibe selber arma3 server des wege kin ich das alles schon
nur mit mit extDB2 kans du das machen
Ich weiß nicht, wo solche Aussagen herkommen. Wenn du noch keinen Server auf Linux Basis betrieben hast, solltest du nicht solche Aussagen treffen.
Um das problem zu lösen:
Hast du die 64bit Version von extDB3? Wie sehen dann die Abhängigkeiten von der extDB3_x64.so aus?
Denn ansonsten kannst du den Server mit 32Bit starten (arma3server). Dann sollte extDB3 laden.
Deine Variable _value ist ein Text, muss aber ein Array sein.
Prüfe Mal, wo die Variable gesetzt wird.
Den Abschnitt den ich geschrieben habe, kannst du direkt einfügen/ersetzen. Du musst natürlich noch den Abschnitt für die anderen Items ändern.
In der Programmierung machen die Klammern (), [], {} gewaltige Unterschiede.
() umschließen Code, der zu erst ausgeführt wird
[] stellen Arrays (Listen) dar
{} markieren Programmabschnitte, die von if-Abfragen oder Schleifen ausgeführt werden
Wenn die anderen Items sich ebenfalls in der entsprechenden Config befinden, dann ja. Ansonsten sollten sie nicht hinzugefügt werden.
In so einem Fall würde ich eigentlich fest mit einem Fehler rechnen.
Das Problem liegt darin, dass in dem Config Pfad kein Array mit den kompatiblen Klassen ist, sondern jede Klasse als eigener Konfigeintrag mit dem Wert 1 vorhanden ist.
Das Bedeutet, dass das du die Einträge anders abfragen und hinzufügen musst. Hier ein Beispiel (Zeile 449-454):
_soldierPrimaryMuzzles = []; _soldierPrimaryMuzzles = configProperties [configFile >> "CfgWeapons" >> _soldierPrimaryWeapon >> "WeaponSlotsInfo" >> "MuzzleSlot" >> "compatibleItems"];
if ((count _soldierPrimaryMuzzles) >= 1) then
{
_soldierPrimaryMuzzle = selectRandom _soldierPrimaryMuzzles;
_soldier addPrimaryWeaponItem configName _soldierPrimaryMuzzle;
};
Mit configProperties werden die Einträge als Array ausgelesen.
Mit configName, wird der Name (der mit der Klasse identisch ist) des ausgewählten Eintrags ausgelesen.
Ihr könnt eure Scripts so anpassen, dass sie mit der neusten Version von Task Force Arrowhead Radio funktionieren. Dadurch könnt ihr alles auf die neuste Version updaten und es nutzen.
Die einfachere Variante ist, wenn niemand seine Version updatet und alle die alte Version nutzen.
Rein aus interesse, ist der Name vom Chip oder der Plate rein zufällig selber wählbar? Also könnte mein Kennzeichen sowas sein: "OR 1=1; DROP TABLE players; --" ?
Wollte darauf hinaus das es kein prepared statement zu sein scheint und theoretisch so sehr anfällig für sql injection.
Sollte kein großes Problem sein. Denn meines wissens nimmt extDB3 immer nur einen SQL-Befehl. Sollten mehrere Befehle erkannt werden, gibt es einen Fehler.
Zumindest habe ich gerade dies auf dem Server ausgeführt:
"extDB3" callExtension "0:SQL:SELECT COUNT(*) FROM player; TRUNCATE statistics; SELECT COUNT(*) FROM player"
Dadurch gibt es folgenden Fehler:
[14:48:59 +02:00] [Thread 1314574] extDB3: SQL: Error MariaDBQueryException: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'TRUNCATE statistics; SELECT COUNT(*) FROM player' at line 1
[14:48:59 +02:00] [Thread 1314574] extDB3: SQL: Error MariaDBQueryException: Input: SELECT COUNT(*) FROM player; TRUNCATE statistics; SELECT COUNT(*) FROM player
Wenn ich allerdings SELECT COUNT(*) FROM player; TRUNCATE statistics; SELECT COUNT(*) FROM player direkt auf die Datenbank ausführe, wird die Tabelle "statistics" geleert.
Ich habe zuvor auch diesen Befehl "extDB3" callExtension "0:SQL:TRUNCATE statistics" ausgeführt, um zu testen ob er grundsätzlich funktioniert.
Bevor die Frage kommt, ja ich habe immer dafür gesorgt, dass wieder Einträge vorhanden sind.
Aber auch so sind preparedStatements der bessere Weg und es ist vorteilhaft diese zu nutzen.
Sehr gut das du es hinbekommen hast.
Führst du denn bisher schon Datenbank-Abfragen Clientseitig aus, oder wie machst du es bisher?
Dann schau wie es bisher funktioniert, oder gib die Funktion für remoteExec frei. Wobei dies normal mit guter Absicht nicht freigeschaltet ist.
Ansonsten kannst du eine weitere Funktion Serverseitig erstellen (nur mit dem Aufruf der Datenbank-Funktion), die du per remoteExec aufrufst, die dann die wirkliche Datenbank-Abfrage durchführt. Somit kann nicht jeder alles an die Datenbank senden.
Jetzt ist der Scriptfehler zwar weg, aber kein Datenbankupdate - Jetzt herrscht komplette Verwirrung
Dann schau mal in die Serverlog was dort ausgegeben wird.
Vor allem auch in die extDB-Log.
Oder einfach _query oben in private []; hinzufügen?
private ["_vehicle","_chip","_thread","_cpRate","_title","_progressBar","_titleText","_cp","_ui","_plate","_owner","_query"];
Mach es nicht. -> private-Performance
Man sollte sowieso den besseren Syntax verwenden.
SQF hat aber kein Problem damit, wenn man eine Variable nicht mit private deklariert, da durch "_" die Variable automatisch private wird.
Vielen Dank für die super schnelle Rückmeldung. Was mich jetzt aber nach deiner Aussage wundert, ist das die anderen Scripts ohne remoteExec laufen - Ich bin etwas verwirrt.
Ich teste es schnell und werde gleich berichten !
Liegt daran, weil es dann auf dem Server ausgeführt wird und der Server die Funktion kennt.