Deine Variable _value ist ein Text, muss aber ein Array sein.
Prüfe Mal, wo die Variable gesetzt wird.
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.
Dein Script befindet sich in der Mission und wird Clientseitig ausgeführt. Du möchtest dann aber eine Funktion aufrufen, die sich nur Serverseitig befindet und somit der Client nicht kennt. Daher kommt richtigerweiße eine Fehlermeldung.
Du musst also dem Server mitteilen, dass er die Funktion aufrufen soll. Das ist mit remoteExec möglich.
Nach dem ändern der Zeile, sollte alles richtig funktionieren.
Super das du Interesse hast einen Server aufzubauen. Ich suche seit längerem Leute die noch Visionen haben.
Vielleicht hast du ja Interesse, gemeinsam etwas zu erschaffen. Ich habe vor kurzem auch ein Thema angelegt, bei dem du vielleicht mal reinschauen möchtest. -> Unterstützung für GLife gesucht
Hallo Zusammen!
Durch viele schlechte Erfahrungen auf verschiedenen Life-Servern, war mein Plan einen Life-Server ins Leben zu rufen, bei dem sich jeder wohl füllt. Ich habe einige Entwürfe erstellt und mich auf die Suche nach einem Life-System begeben, dass meine Anforderungen erfüllt. Nach dem Ausprobieren mehrerer Systeme, stellte sich sehr schnell herraus, dass keines so wirklich passt. Sie anzupassen stand in keinem Verhältnis, also habe ich mich dazu entschieden ein neues Life-System ins Leben zu rufen.
Warum ein eigenes Life-System?
Die bestehenden Life-Systeme sind nicht flexibel genug sind, außerdem gab/gibt es noch immer schwerwiegende Fehler, die sich nur mühselig beheben lassen. Zusätzlich liegt mir die Performance sehr am Herzen.
Ursprünglich war das System ein Open-Source Projekt. Meine Hoffnung war, dass sich viele andere Arma Begeisterten dem Projekt anschließen und für ihre Server das neue Life-System verwenden.
Was ist gesucht?
Nun arbeite ich schon seit längerem großteils alleine daran. Es gab hin und wieder ein paar helfende Hände, die dann aber aus privaten Gründen ausgeschieden sind. Nun suche ich auf diesem Weg Unterstützer, die das Projekt lange begleiten und groß machen wollen.
Sei es beim Scripten ist, beim Erstellen der Karte oder beim Festlegen der Regeln und Wirtschaft. Jeder der Interesse hat und helfen möchte ist herzlich willkommen. Dabei werden keine großen Anforderungen gestellt. Interessenten sollten nur Zuverlässigkeit, Selbstständigkeit und Interesse mitbringen. Denn ich vertrete die Meinung, dass wenn jemand etwas lernen und machen möchte, er es schaffen kann. Ich unterstütze jeden beim Erlernen der Fähigkeiten, um am Projekt mitwirken zu können.
Teamstruktur
Die Teamstruktur soll sehr flach werden. Jeder Mitwirkende hat das selbe Mitspracherecht. Entscheidungen werden gemeinsam besprochen, entschieden und getragen. Unstimmigkeiten sollen durch frühzeitige Kommunikation bereits geklärt und gelöst werden. Natürlich in allseitigem Einverständnis.
Pläne
Ich habe mich vollkommen auf den Scripting-Bereich fokussiert. Da die Scripts die Kernelemente sind, sollen diese weiter vorangetrieben werden. Viele grundlegende Funktionen wurden bereits implementiert, die sich bereits jetzt von anderen Life-System abheben. Dies soll in Zukunft noch weiter ausgebaut werden. Zeitgleich soll bereits an der Karte gebaut werden, damit die Funktionen getestet werden können und eine allgemeine Testphase starten kann. Dafür sollen auch die Wirtschaft und Regeln grundlegend stehen, dann weiter verfeinert und auf Schwachstellen überprüft werden.
Infrastruktur
Die Entwicklung des Life-Systems erfolgt vollständig über Gitlab. Die dafür benötigten Kenntnisse erkläre ich Interessenten natürlich gern.
Alle Systeme werden selber gehostet. Für Arma stehen dafür auch Test-Server zu Verfügung, bei denen die PBOs automatisiert eingefügt werden.
Wie kann man mitwirken?
Das Einfachste ist mich direkt anzusprechen. Dafür stehen mehrere Möglichkeiten zu Verfügung.
Zum Reden am besten TeamSpeak: gallina.group
Schriftlich bietet sich Discord an.
Ich freue mich über neue Unterstützung, aber auch allgemein Interessierte, die dann den Server mit Leben füllen wollen.
Bis dahin können sie neue Funktionen testen und so die Entwicklung unterstützen.
Sollte ich Punkte vergessen haben, füge ich diese auf Nachfrage gern hinzu.
Freundliche Grüße Henne
Dein Ziel ist beim Button die Farbe zu verändern. Das kannst du mit ctrlSetTextColor anstellen. Mit dem Command sollte sowohl der Text, als auch das Icon die Farbe ändern.
Um den weißen Strich Farbig zu machen, kannst du ctrlSetBackgroundColor verwenden.
Wichtig ist natürlich auch, beim klicken eines Buttons die Farben der anderen Buttons wieder weiß zu machen.
Wenn du die Anleitung gelesen hast, ist dir sicherlich folgender Abschnitt aufgefallen.
- Hast du eine Kontrolle für Remote-Execution aktiv CfgRemoteExec.h/hpp, dann wird folgendes unter Funktionen benötigt
Code Alles anzeigenF(fvs_fnc_perso_laden,CLIENT) // Perso F(fvs_fnc_persoBeantragen,CLIENT) // Perso F(fvs_fnc_persoCheck,CLIENT) // Perso F(fvs_fnc_persoErgebnis,CLIENT) // Perso F(fvs_fnc_persoNeu,CLIENT) // Perso F(fvs_fnc_updateMonat,CLIENT) // Perso F(fvs_fnc_updateTag,CLIENT) // Perso F(fvs_fnc_zeigePerso,CLIENT) // Perso F(fvs_fnc_updatePersoBild,CLIENT) // Perso F(DB_fnc_persoRequest,SERVER) // Perso F(DB_fnc_persoInsert,SERVER) // Perso F(DB_fnc_persoUpdate,SERVER) // Perso
Wie da auch hervorgeht, musst du die Zeilen unter Functions hinzufügen.
Den Abschnitt solltest du sehr sicher haben und wenn wirklich nicht, dann füge ihn einfach hinzu.
Dann schau was in der normalen Serverlog steht.
Je nachdem was ihr für einen Server habt, gibt es da ganz verschiedene Varianten.
Es gibt oft einen Ordner der "logs" heißt. In dem sich dann die Logs befinden. Ansonsten befinden sich die Logs in %appdata%\local\arma3.
Für extDB Logs muss man natürlich entsprechend in extDB schauen.
Dann wird wohl etwas mit der Datenbank-Verbindung nicht stimmen.
Schaue in deine Logs was da steht und behebe den Fehler. Danach funktioniert wieder alles.
Jop, allerdings leider auch kein Fehler dahingehend drin.
Ich gehe davon aus, dass irgendwo einer der Werte die du geändert hast falsch gesetzt ist.
An welchen Stellen in den Dateien hast du überall Änderungen gemacht und was für Werte hast du geändert?
Die Client-Log wäre ebenso interessant.