Beiträge von Henne

Zitat von Alice Kingsleigh

Das ist eine Umgehung des Problems, aber doch keine LÖSUNG

Nunja, Grundsätzlich ist es eine Lösung.

Denn Arma löscht die Objekte nicht richtig. Man löscht somit die Objekte nochmal gezielt und sie sind auch wirklich weg.

Dadurch kommt auch die Meldung nicht mehr.

Wenn du die Objekte richtig löschen möchtest, schreib Bohemia an und bitte darum, dass die Objekte richtig entfernt werden.

Deathman

Das hat nichts mit der Datenbank zu tun.

Es geht hier rein um Objekte während der Laufzeit, die entfernt wurden.

https://feedback.bistudio.com/T82940

Dann solltest du auch mal die Client-Log schicken.

Die Vermutung ist nicht ganz richtig, geht aber in die richtige Richtung.

Nehmen wir diese Meldung:

Server: Object 2:42 not found

Wie ich schon sagte, ist dies die NetID des Objektes.

Mit objectFromNetId "2:42" kann man das Objekt erhalten.

Um die Meldung zu entfernen, kann man das Objekt mit deleteVehicle (objectFromNetId "2:42") löschen.

Dadurch ist die Meldung weg.

Hast du denn nun schon das Objekt wieder platziert und erneut getestet?

Auf der Karte gibt es ein Objekt, dass den Namen master_group hat. Das hast du einfach gelöscht.

Also setze es wieder hin fertig.

Der Client lädt niemals die Datenbank.

Denn die Datenbank ist auf dem Server und kann nur von diesem geladen werden.

Zitat von Navex

Hey, ich habe ein Problem, ich vermute, dass das der Fehler ist, . . .

18:26:47 Error in expression <query,1] call DB_fnc_asyncCall;

Das ist ja auch nicht der Fehler.

18:26:47 Error in expression <query,1] call DB_fnc_asyncCall;
};
};


master_group attachTo[bank_obj,[0,0,0]];>
18:26:47   Error position: <master_group attachTo[bank_obj,[0,0,0]];>
18:26:47   Error Undefined variable in expression: master_group
18:26:47 File life_server\init.sqf..., line 89

Wie nun mit der kompletten Fehlermeldung zu erkennen ist, ist master_group nicht definiert.

Definiere es und alles ist wieder in Ordnung.

Wie ich das ganze in Discord nun schon öfters ausgiebig erklärt habe, hier halt dann nochmal.

Auch hier wiederhole ich mich schon:

Der Fehler wird erzeugt, wenn auf Objekte zugegriffen werdern soll, die nicht mehr vorhanden sind.

Daraus ergibt sich nur eine logische Schlussvolgerung:

Die Objekte wurden nicht vollständig entfernt.

Daher muss das Objekt vollständig entfernt werden. Dann taucht der Fehler nicht mehr auf.

Wie sich nun das entfernen umsetzen lässt, ist Code abhängig.

Mit ESLife haben wir eben die Möglichkeit, diese Meldungen fast vollständig zu entfernen.

Wieviel Aufwand es ist, dies auch in Tonic umzusetzen, keine Ahnung.

Immer dann wenn Objekte nicht mehr vorhanden sind, auf die gerade zugegriffen werden soll.

Ausstellen geht nicht. Aber beheben.

Bisher habe ich einen guten Weg eingeschlagen und viele Meldungen beseitigt.

Vereinzelt tauchen sie noch auf. Aber da schaue ich noch, wie ich das beseitigen kann.

Das ist richtig, dass es komisch aussieht. Aber Altis und die ganzen Objekte siehst du doch. Also ist das Addon vorhanden.

Die Fehlermeldug, dass die Objekte nicht vorhanden sind, tritt in der Laufzeit auf und betrifft Objekte die nicht mehr vorhanden sind.

Das hat nichts damit zutun.

Überlegen wir mal, was es für Gründe hat, dass ein Objekt nicht mehr da ist.

Vermutlich wurde es entfernt.

Wenn viel Aktion auf dem Server ist, dann werden ständig Objekte gesetzt und wieder entfernt.

Der Fehler taucht dann auf, wenn ein Objekt nicht mehr da ist, auf das gerade zugegriffen wird.

Zitat von TaktischerSpeck

er tritt im server sowie HC log auf

Ich verrate dir, dass die Fehlermeldung auch bei den Clients auftaucht.

Die Meldung hat nichts mit höheren Pings zu tun.

Die Meldung besagt einfach, dass ein Objekt nicht vorhanden ist (steht ja auch so in der Fehlermeldung).

Sehr viele sind der Meinung, dass die Meldung einfach ignoriert werden kann/soll.

Natürlich lässt sich die Meldung ignorieren. Allerdings bin ich der Meinung, dass es Gründe hat, warum Meldungen ausgegeben werden.

Ob du etwas am HeadlessClient falsch gemacht hast, lässt sich so nicht wirklich sagen.

Allerdings taucht die Meldung im HeadlessClient auch auf und daher liegt das Problem auf jeden Fall auch noch woanders.

Zitat von SelfTanoa

vielen dank für deine hilfe aber könntest du mir verraten wie du auf zeile 83 kommst wenn da 138 oder wird das rückwärts gelesen ?

Da wird nichts rückwärts gelesen.

Die Stelle zu finden ist ganz einfach, wenn man sich die Fehlermeldung genau anschaut.

18:02:32 Error in expression <se {_trunkSpace},
_vehicleInfo select 12),
_vehicleColor,
[_insurancePrice] call>
18:02:32 Error position: <),
_vehicleColor,
[_insurancePrice] call>
18:02:32 Error Missing ]
18:02:32 File dialog\function\fn_garageLBChange.sqf [life_fnc_garageLBChange]..., line 138

Die Fehlermeldung beinhaltet folgende Informationen:

1. Code Ausschnitt mit Fehler
2. Exakte Fehlerposition
3. Fehlerbeschreibung
4. Fehlerhafte Datei mit fehlerhaften Zeile
5. Zeit wann der Fehler aufgetaucht ist

Sehen wir uns nun die einzelnen Informationen an:

Error in expression <se {_trunkSpace},
_vehicleInfo select 12),
_vehicleColor,
[_insurancePrice] call>

Dies bedeutet, dass der Fehler zwischen den <>  ist.

Error position: <),
_vehicleColor,
[_insurancePrice] call>

Der fehlerhaft Code ist auch in Error in expression zu finden. Somit lässt sich also der Fehler bereits finden.

Mit ein wenig Verständniss, ist auch schon zu erkennen was der Fehler ist.

Error Missing ]

Die genaue Fehlerbeschreibung.

Beinhaltet die Beschreibung des Fehlers und teilweiße auch, wie es richtig gehört.

z.B. Error Undefined behavior: waitUntil returned nil. True or false expected.

File dialog\function\fn_garageLBChange.sqf [life_fnc_garageLBChange]..., line 138

Hier wird die fehlerhafte Datei mit fehlerhaften Zeile beschrieben.

Die Uhrzeit zeigt an, um wieviel Uhr der Fehler aufgetaucht ist.

Hilfreich, wenn man wiederkehrende Fehler sucht (ob der Fehler regelmäßig auftaucht), oder man weitere Logs hat um dort weitere Informationen auszulesen.

Ziehen wir nun unsere Schlüsse aus den Informationen:

1. Wie in 3. zu erkennen ist, fehlt eine ].
2. Wir suchen in 2. die exakte Position. Der Fehler wird durch die ) (erstes Zeichen nach <) erzeugt.
3. Wir können nun versuchen mithilfe von 1. den Fehler direkt zu finden (in diesem Fall möglich, klappt aber nicht immer).
   Oder wir suchen mithilfe von 4. die fehlerhafte Stelle in der Datei. Sollte die Zeile nicht so aussehen, wie wir erwarten, suchen wir die Zeile mithilfe des Code Ausschnitt von 1. (in diesem Fall Zeile 83).
4. Wir beheben den Fehler, je nachdem was für ein Fehler es ist.

Sonderfälle:

Wie zu erkennen ist, gibt es in diesem Fall Unstimmigkeiten:

1. Die Fehlerbeschreibung ist irreführend.
2. Die Zeilenangabe scheint nicht zu stimmen.

Auf dem ersten Blick scheint die Fehlerbeschreibung falsch zu sein. Allerdings trifft sie vollkommen zu.

Dazu dieser Beispielcode:

(
    [
        )    // fehlerhafte Stelle wie in deinem Fall
    ]
)

Da mit der fehlerhaften ) die ( geschlossen wird. Stellt Arma fest, dass ein ] innerhalb der ( ) fehlt und gibt daher die Fehlermeldung aus.

Weiter stimmt anscheinend die Zeilenangabe nicht.

In der ersten Zeile wird eine weitere Datei includet. Dadurch verändert sich die Datei.

Auch hierzu ein Beispielcode:

/* 
 * Beispiel Code mit Kommentar um Zeilen zu erzeugen.
 */

CODE

#include "DATEI1"

(
    [
        )    // fehlerhafte Stelle
    ]
)

Fie Fehlermeldung besagt, dass sich der Fehler in DATEI2 in Zeile 9 befinden soll. Allerdings ist die DATEI2 nur 7 Zeilen lang.

Stellen wir nach, was Arma beim starten macht:

Arma includet in die DATEI2, an der gewünschten Stelle die DATEI1.

Das schaut dann so aus:

/* 
 * Beispiel Code mit Kommentar um Zeilen zu erzeugen.
 */

CODE

(
    [
        )    // fehlerhafte Stelle
    ]
)

Was sehen wir nun?

Der Fehler befindet sich in DATEI2 in Zeile 9.

Sonderfall:

Macros (alles was mit # beginnt) werden beim starten kompiliert und tauchen daher im Code nicht mehr auf. Dadurch werden diese auch nicht zu den Zeilen gezählt.

Daher bin ich kein Freund davon, Macros innerhalb von Code zu verwenden, da diese nur die Fehlermeldungen verändern.

Auch wenn das ganze nun ein wenig länger geworden ist, ich hoffe ich konnte dir das ganze ein wenig näher bringen.

Zitat von SelfTanoa

allerdings geht diese datei nicht bis zur zeile 138 sondern nur bis 97

Du includest in der ersten Zeile die Datei ..\..\script_macros.hpp. Dadurch musst du die Zeilen zu deiner Fehlermeldung dazu zählen.

Die Zeilenangabe ist in diesem Fall aber auch nicht unbedingt notwendig. Denn dies ist die Fehlermeldung:

Zitat von SelfTanoa

18:02:32 Error in expression <se {_trunkSpace},

_vehicleInfo select 12),

_vehicleColor,

[_insurancePrice] call>

18:02:32 Error position: <),

_vehicleColor,

[_insurancePrice] call>

18:02:32 Error Missing ]

18:02:32 File dialog\function\fn_garageLBChange.sqf [life_fnc_garageLBChange]..., line 138

Alles anzeigen

Die Fehlermeldung beinhaltet alle Informationen um den Fehler zu finden.

Unter dem Punkt Error position: wird die genaue Fehlerstelle beschrieben.

Der Fehler zeigt also auf die Klammer in Zeile 83.

Zeile 83: _vehicleInfo select 12),

Viel Spaß beim Rätseln.

Schau in der letzten Zeile.

Eine Bedingung muss immer einem booleaschem Wert entsprechen. Allerdings ist eine Zahl kein booleascher Wert.

Denn was soll z.B. 1000 darstellen?

Zahlen können auf mehreren Wegen geprüft werden. Dazu gehört ob die Zahl größer, kleiner oder gleich eine andere Zahl ist.

Was in diesem Fall aber die gewünschte Variante ist, muss du festlegen.

Du kannst natürlich das Semikolon entfernen.

Allerdings behebt das nicht den Fehler. Denn der Fehler besagt, dass die Variable _kassa innerhalb der Bedingung nicht definiert ist.

Um den Fehler zu beheben, muss die Variable zuvor definiert werden.

Für kleine Änderungen hilft z.B. Notepad++.

Denn Notepad++ markiert die öffnende und schließende Klammer farblich.

Den Spoiler hast du dir aber schon angeschaut?

Wenn du es wirklich nicht finden solltest, gib nochmal bescheid.

Also das du tausendemale nochmal alles geprüft hast, kann ich mir nicht so wirklich vorstellen. Denn ich habe den Fehler innerhalb von 10 Sekunden gefunden.

1. Man öffne die Config_Vehicles.hpp

2. Man zähle die {

3. Man zähle die }

4. Man stellt fest, dass ein } zuwenig vorhanden ist

5. Man sucht bei welcher Klasse die } fehlt

6. Man fügt die fehlende } ein

Kleiner Hinweis:

Wer Tonic-Life nutzt, darf auf die Zeilen-Angaben nicht vertrauen.

Ein entsprechender Editor, der die zugehörigen Klammern markiert hilft bei der Suche.

Natürlich speichern und hochladen nicht vergessen.