Ich wollte es nicht umschreiben, da der Ersteller des Systems ein gentlich darauf bestand dass er hier gelöscht wird.
Ich respektiere seinen Wunsch dass er alle seine Tutorials nicht weiter verbreitet haben will. Sorry.
Schön, dass du den Weg zu NodeZone.net gefunden hast! Aktuell bist du nicht angemeldet und kannst deshalb nur eingeschränkt auf unsere Community zugreifen. Um alle Funktionen freizuschalten, spannende Inhalte zu entdecken und dich aktiv einzubringen, registriere dich jetzt kostenlos oder melde dich mit deinem Account an.
Ich wollte es nicht umschreiben, da der Ersteller des Systems ein gentlich darauf bestand dass er hier gelöscht wird.
Ich respektiere seinen Wunsch dass er alle seine Tutorials nicht weiter verbreitet haben will. Sorry.
Die Battleeye filter sind eh unnötig. Hol dir Infistar und mach die von denen rein oder sogar komplett raus.
Das dachte ich auch immer. Allerdings ist es eher anders rum. InfiSTAR ist eines der schlechtesten Tools. Allerdings nicht wirklich das Tool, sondern alle die das Tool zu Verfugung haben. Er wird hauptsächlich zum trollen genutzt. Es hat nicht umsonst den Spitznamen Trolltool.
Und leider ist gegen Hacker nichts so effektiv wie die Battleeye Filter. Das lernst du du dann, wenn du mal Besuch von netten Leuten bekommst und dir den infiSTAR überhaupt nichts mehr hilft.
es müssen nur ein paar Kleinigkeiten abgeändert werden. Zwischen der 4.0 und der 5.0 sind ein paar Sachen anders.
und welchen fehler haste in den logs ?
Spoiler öffnen und lesen.
wird KEKON überhaupt noch supportet?
schau im Battleeye Ordner nach der entsprechenden log Datei. Dann träg den Grund den du da drin stehen hast für den Kick in die txt Datei zu dem betreffenden Filter . er sagt dir beim kick ja welche log \ txt Datei betroffen ist.
ich verstehe grad gar nicht was das für ein Glitch sein soll.etwas verwirrt.
Ich finde die Drogen sollten generell nicht zu kaufen sein.
Aber ist das dann nicht bei allen items so?
Also als erstes hast du den Dyn Market eingefügt. Allerdings da die Version die für < 4.0 ist. Das siehst daran, dass du mehrfach "life_fnc_MP" drin hast, das gibt es ab der Version 4.4r3 nicht mehr und dadurch geht da erstmal Garnichts. Du musst beim Einfügen schon auf die Version achten oder das dann umschreiben. Ab der Version 4.4r3 gibt es z.B. auch kein SVAR / GVAR usw. nur heißt das setVariable / getVariable. Wenn du darauf nicht achtest, bekommst immer mehr Fehler. Und gewöhn dir an erst die Fehler zu beheben und dann das nächste einzubauen. Weil du evtl. gar nicht mehr nach den richtigen Fehler suchst. Wenn ein Fehler schon die DB blockt, kann der nächste netmal mehr drauf zugreifen obwohl bei dem Script alles ok wäre. Laut deinem Log kommst du nicht mal mehr bis zum Perso Zeug. dein Dyn Market legt dir scheinbar den gesamten Server lahm.
Also laut deinem Log, such dir entweder die ganzen Fehler raus und bring erst die in Ordnung ( Hier eigentlich alles vom Dyn Market )oder du macht den Dyn Market rückgängig und suchst dir das richtige Tut für deine Version. blackfisch hat auch ein Tut geschrieben wie man diese life_fnc_MP Sachen umschreibt zu den remoteExec Sachen, die bei der 4.4r3 verwendet werden. Denke auch dass deine DB Abfragen ( für die alte Dyn Market Version ) nicht mehr mit deiner extDB3 funktionieren, da wirst sicher auch Probleme haben, falls er überhaupt soweit kommt.
hat sich geklärt. Hatte nur ne Klammer Zuviel.jetzt geht es so wie gewollt.
Shadow l Eagle kann geschlossen werden.
Solange sich ja die Mission nicht durch ein Update verandert ist es ja wurscht. Und dann kann man auch mal den Launcher und Arma zu machen und wieder öffnen
Aber das Kann doch nicht sein das man Jedesmal sein Arma Neustarten muss. Da muss doch ein Fehler vorhanden sein (Bei Anderen ist es ja auch nicht)?
Doch das ist bei vielen so. Und trifft wohl jeden irgendwann Das einzige was es etwas vermindert, wenn man der mission nicht nen eigenen Namen gibt. Bei mir zB. OutlawIsland_Life.Tanoa Sondern einfach Tanoa_Life.Tanoa beläßt.
ich lese dann in der Datei fn_requestReceived.sqf den Code wieder aus mit:
life_code = parseNumber (_this select 16);
Damit sollte doch nun der 4 Stellige Code in der Variable stehen, oder nicht?
Ind beim Spawn schaut er ja ob die Vasriable == 0 ist, wenn ja Code eingabe öffnen, wenn nein einfach normal weiter machen.
Hast du auch bei der query dies in der select abfrage eingebaut?
je nach dem welche seite gespielt wird unterscheidet sich der index des parameters, dies muss in der query eingetragen werden und danach musst du mit einer if bedingung abfrage welche seite gespielt wird und dann kannst erst den richtigen parameterindex abfragen
Meinst du in der fn_queryRequest.sqf?
Dort hab ich es drin. Aber keine Ahnung ob die select Position passt. Kann ich das irgendwie nachschauen welche possition das nun wirklich hat?
_query = switch (_side) do {
// West - 11 entries returned
case west: {format ["SELECT pid, name, cash, bankacc, adminlevel, donorlevel, cop_licenses, coplevel, cop_gear, blacklist, cop_stats, playtime, code FROM players WHERE pid='%1'",_uid];};
// Civilian - 12 entries returned
case civilian: {format ["SELECT pid, name, cash, bankacc, adminlevel, donorlevel, civ_licenses, arrested, civ_gear, civ_stats, civ_alive, civ_position, playtime, jail_time, code FROM players WHERE pid='%1'",_uid];};
// Independent - 10 entries returned
case independent: {format ["SELECT pid, name, cash, bankacc, adminlevel, donorlevel, med_licenses, mediclevel, med_gear, med_stats, playtime, code FROM players WHERE pid='%1'",_uid];};
};
Es geht um den "Code"
Habe unten dann in der Datei die Abfragen in den Cases:
_tmp = [(_queryResult select 12)] call DB_fnc_mresToArray;
_queryResult set[16,[_tmp] call DB_fnc_numberSafe];
_tmp = [(_queryResult select 14)] call DB_fnc_mresToArray;
_queryResult set[16,[_tmp] call DB_fnc_numberSafe];
_tmp = [(_queryResult select 11)] call DB_fnc_mresToArray;
_queryResult set[16,[_tmp] call DB_fnc_numberSafe];
Hallo zusammen,
ich stehe noch etwas auf Kriegsfuss mit den Datenbank abfragen etc.
Ich möchte gerne beim betreten des Servers, dass eine Zahl aus meiner Player Table in der Spalte Code ausgelesen wird. Damit soll dann die
Variable life_Code gesetzt wird. Es ist eine 4 Stellige Zahl drin in dem Feld. Wenn noch kein Code eingegeben wurde, sollte da eine 0 drin stehen,
was auch funktioniert. Auch das Abfragen eines neuen Codes geht und das rein schreiben. Aber ich stehe gerade total auf dem Schlauch und
weiß nicht wie ich das wieder auslese. Weil wenn da schon eine 4 Stellige Zahl drin ist, dann sollte man auch nicht wieder einen Code eingeben
müssen.
in der Datei /coreinit.sqf habe ich die Abfrage drin ob die Variable life_Code == 0 ist, dann öffnet er die Code eingabe und man kann einen neuen
Code eingeben. Aber das kommt nun halt immer, weil er den Code nicht ausließt. Wo müsste denn dieses Auslesen rein?
Ich habe in der fn_requestReceived.sqf diese Zeile eingefügt, dachte das würde so gehen:
life_Code = parseNumber, (_this select 16);
Kann es vielelicht sein, dasss ich die falsche Stelle habe?
MfG
Saturin78
geht nicht
Muss gehen, läuft bei mir mit Tanoa 5.0.0 + extDB3 auch. Musst nur alle Beiträge beachten. ZB. Dass du die DB sachen der extDB2 RAW nimmst und so weiter. Aber lief auf Anhieb mit den ganzen Informationen.
Aso, nee bei den 750 musst du deinen Preis eintragen was bei Server start sein soll. Von dort aus wandert er hin und her wenn was verkauft wird.
Äh ok.
Das versteh ich jetzt nicht ganz. Bei mir bewegt er sich innerhalb der Spanne hin und her. Das ist deshalb, damit man einen Preis nicht quasi auf 0 fahren kann oder auf keine Ahnung wieviel Millionen.
Uff, also ich habe auf meinem Testserver die Version 4.0 laufen und da kann ich die sachen die nicht eingetragen sind weiter verkaufen. Bei meiner 5.0 die ich auf dem Testserver habe auch. Da ist noch nichts eingetragen außer Äpfeln
Aber da ist eine Datei in der was von Blacklist steht. Da kannst Sachen eintragen die nicht angezeigt werden sollen. Weiss nur net genau welche Datei das war. Bei mir war da als Beispiel Apfel drin, darum tauchten bei mir die Apfel nicht auf im Marktsystem.