Beiträge von Cris

Eine PublicVariableRestriction kommt durch fehlerhafte BattleEye Filter zu Stande. Glaube, ihr habt nicht nur einen Fehler in euren Configs ?

Ja darum geht es ja, dass die Zufälligkeit des Ergebnisses verfälscht wird. Jedoch darf (kann sein, dass du darauf hinaus wolltest) in einem gecalltem Script kein sleep vorkommen.

EDIT

Daher eine bessere Variante Spawne die Funktion life_fnc_sexkrankeit und übergebe hier die Variable _bereit als Parameter und lasse am Ender der Funktion dann die selectRandom Funktion ausführen.

Naja, wenn du gerade erst anfängst, dann ist das natürlich nicht so einfach umzusetzen. Da sollte man schon ein wenig Erfahrung in der Programmierung haben und sich mit Regex auskennen.

Bei uns war es jedenfalls so, dass wir eine Datei initPlayerLocal.sqf (hat eigentlich jede Mission) hatten, in der wurde ein FSM Script ausgeführt, welches sich init.fsm (bei uns) nannte und in diesem gab es in einem Codeblock die ausführung eines weiteren Scriptes namens fn_nameCheck.sqf. Und in diesem Script haben wir 1. getestet ob die PlayerUID zu dem angelegten Namen in der DB passte und ob der Name gewissen Richtlinien entsprach, keine Sonderzeichen etc.

Ich weiß garnicht mehr, wie die Initialisierung beim Standardscript genau ausschaut, wir haben es halt als FSM Script gemacht, weil die performanter sind als SQF.

Diese Möglichkeit gibt es. Im Initialisierungsscript des Clients kann ein Check in Form einer Regex-Abfrage des Spielernamens eingefügt werden. Wenn der Name des Spielers nicht valid zum Regex Ausdruck ist, kann ein Kick Befehl mit Angabe der Gründe ausgeführt werden.

_array = [call life_fnc_sexkrankheit,hint _bereit;];

_random = selectRandom _array;

Das Array besteht aus dem Ergebnis des Aufrufes der Funktion life_fnc_sexkrankheit und dem hint der Variable _bereit.

Die Variable _random wird definiert durch einen zufälligen Wert des Arrays namens _array.

Wenn also hier spawn life_fnc_sexkrankheit verwendet werden würde, kann es passieren, dass das Array bei der Definition von _array wie folgt aussieht:

[NULL, "Du kannst jetzt wieder Neue Dienste in Anspruch Nehmen"]

ZorG: Wenn an dieser Stelle ein Spawn verwendet wird, würde es dazu kommen, dass die Variable _random nicht definiert werden kann, weil die Ausführung des 2. Scripts über Spawn parallel betrieben wird. Und somit die Variable _array zu dem Zeitpunkt nicht definiert ist, wenn sie bei der Definition von _random benötigt wird.

Deswegen muss hier auf die Ausführung des 2. Scripts gewartet werden und somit muss an der Stelle call bleiben.

Deine live_inv Variablen sind keine Zahlen, was den Datentyp angeht. Aus diesem Grund mache da bitte folgendes:

if (call live_inv_pille > 0) then {...}...

Das selbe auch mit live_inv_kondom

Selber darfst du ja nicht die live_server Mod bei deinem Arma laden. Die muss nur beim Server geladen (über Parameter) werden.

verifySignatures = 0;

Der Wert sollte 2 sein.

Bitte poste mal deine server.cfg rein, Passwörter etc. kannst du entfernen.

Das schaut mir auch, dass du in deiner Config eingestellt hast, dass der live_server eine benötigte Mod ist.

Der Button wird ja aber dennoch mit der Aktion belegt. Dort wird ja nur gecheckt, ob es sich um ein DLC Fahrzeug handelt und nicht ob der Benutzer die DLCs besitzt.

Du hast aber schon den LiveServer beim Start des ArmaServers über die Parameter mit eingebunden?

Folgender Ausschnitt aus dem ersten Quellcode. Ich würde jetzt mal behaupten, bei dem Interaktionsmenü bei DLC Fahrzeugen kommt bei euch nur "Als Fahrer einsteigen" oder wie es benannt ist und dafür die Funktion Flippen nicht?!

Liegt daran, dass die Funktion des Buttons 6 bei DLC Fahrzeugen so gesetzt wird.

D.h. für die Aktion "Einsteigen als Fahrer" solltet ihr lieber einen neuen Button machen.

if (_curTarget isKindOf "Ship") then {
 _Btn6 ctrlSetText localize "STR_vInAct_PushBoat";
 _Btn6 buttonSetAction "[] spawn life_fnc_pushObject; closeDialog 0;";
 if (_curTarget isKindOf "Ship" && {local _curTarget} && {crew _curTarget isEqualTo []}) then { _Btn6 ctrlEnable true;} else {_Btn6 ctrlEnable false};
 } else {
 if (!isNil "_id") then {
 if !(_id in getDLCs 1) then {
 _Btn6 ctrlSetText localize "STR_vInAct_GetInVehicle";
 _Btn6 buttonSetAction "player moveInDriver life_vInact_curTarget; closeDialog 0;";
 if (crew _curTarget isEqualTo [] && {canMove _curTarget} && {locked _curTarget isEqualTo 0}) then {_Btn6 ctrlEnable true;} else {_Btn6 ctrlEnable false};
 };
 } else {
 _Btn6 ctrlSetText localize "STR_vInAct_Unflip";
 _Btn6 buttonSetAction "life_vInact_curTarget setPos [getPos life_vInact_curTarget select 0, getPos life_vInact_curTarget select 1, (getPos life_vInact_curTarget select 2)+0.5]; closeDialog 0;";
 if (alive _curTarget && {crew _curTarget isEqualTo []} && {canMove _curTarget}) then { _Btn6 ctrlEnable false;} else {_Btn6 ctrlEnable true;};
 };
 };

Das stimmt der Check vor dem Öffnen des Interactions Menü nicht ganz. Da müssen die neuen DLC Fahrzeuge hinzugefügt werden.

ZorG: Wenn du die Arma Engine kennen würdest, wüsstest du, dass Objekte in Arma für den Server eigentlich "Fahrzeuge" sind. Nicht umsonst heißt der Befehl createVehicle.

Das lokale setzten von Objekten auf Spielern kann zu wesentlichen Beeinträchtigungen im Spielerlebnis führen. Denn so ist auch die Hitbox und die Simulation der Objekte bei jedem Spieler völlig anders. Außerdem würde es keine Verbesserungen der FPS beim einzelnen Spieler führen.

Dennoch würde ich "Deko-Objekte", wie es bereits ZorG geschrieben hat, als SimpleObjects setzen, bringt vielleicht ein wenig FPS mehr. Die beste Sache ist aber am Ende immer noch ein oder gar zwei Headlessclients.

Wenn du Fahrzeuge über den Server per createVehicleLocal spawnen würdest, würde dies nicht funktionieren. Das heißt Spieler würden die Fahrzeuge nicht sehen, sondern "nur der Server". Das liegt daran, dass die Fahrzeuge keine NetID bekommen. Mehr dazu auch hier: https://community.bistudio.com/wiki/createVehicleLocal

Wenn du FPS sparen möchtest, lege dir einen HeadlessClient zu, der den Server viele unnötige Aufgaben abnimmt und Somit FPS spart. So kann beispielsweise der HC die Fahrzeuge spawnen.

Viele Grüße

Cris

Hast du in irgendeiner anderen Config oder in der description.ext bereits eine Klasse Namens Cation_Crafting.

Denn laut des Logs wäre Zeile 85 in deiner Config:

{"item","weapon"} //Variablennamen der verfügbaren Kategorien

Und das stimmt nicht mit der Fehlermeldung überein.

Okay, gut.

Habe aber auch noch das im RPT gefunden:

16:14:10 Warning Message: File mpmissions\__cur_mp.Altis\cation\crafting\config.cpp, line 85: .Cation_Crafting: Member already defined.

Prüfe das mal, auch wenn es keinen Fehler vorerst bewirkt, kann es ja später zu Fehlern führen.

Auszug aus dem Arma3Server RPT:

16:14:59 Warning Message: Script \life_server\init.sqf not found

Das SQF-Script für die Initialisierung des Lifeservers kann nicht gefunden werden und ohne das, geht nichts los.

Wenn ich mich recht entsinne (Ist schon ewig und 3 Tage her, als ich das letzte mal für Arma gescripptet habe) checkt das Script vorher um welches Objekt es sich handelt. Dabei ist zu beachten, dass Arma viele verschiedene Objekte als "Fahrzeuge" betrachtet, obwohl diese keine Fahrzeuge sind (CfgVehicles).

Außerdem waren die DLC Fahrzeuge von spezieller skripttechnischer Benennung. Aus diesem Grund musste, glaube mich da noch grob zu erinnern, in dem Skript die neuen Fahrzeuge der DLCs nachgetragen werden, damit beim Check das Script bei DLC Fahrzeugen nicht mehr abbricht.