Fehler in UE5 oder in Visual Studio, oder doch bei mir?

Hallo zusammen.

Ich bin mal wieder total am Verzweifeln.

Ich habe gestern ein neues Projekt gestartet, mit C++ unter UE5.

Ich bin recht gut vorangekommen, habe dann das Projekt testweise erstellt und hatte plötzlich 11184 Fehler. Gut, das bin ich von C++ ja gewohnt, dass ich nicht in jedem Wort des Codes einen Fehler eingebaut haben kann war mir schon klar. Am Ende stellt sich heraus, dass ich bei einem Array ein Komma zu viel hatte.

Danach war die Compilierung erfolgreich, 0 Fehler, 0 Warnungen, alles gut. Abgespeichert und schlafen gegangen.

Heute will ich weitermachen, lade das Projekt und gehe als Erstes auf compilieren, was ich eigentlich gar nicht wollte, aber irgendwie habe ich es halt gemacht. Und bums, wieder die 11184 Fehler. Aber das Komma ist weg, es sieht alles so aus, wie ich es gestern gespeichert habe. Aber er findet meine Headerdateien teilweise nicht, obwohl vorhanden und auch mit include eingefügt usw.

Mal abgesehen davon, dass ja auch nicht die alte Fehlerliste wieder auftauchen kann, wenn gestern alles OK war.

Vor allem wundert mich, was als Fehler gelistet wird.

Unter anderem habe ich einen FVector benutzt:

        FVector(InX:100, InY:100, InZ:100)

InY: erkennt er an, InZ: ebenfalls, aber er meckert an, dass InX kein gültiger Bezeichner ist. Aber es funktionierte gestern und ist laut Dokumentation auch so zu verwenden.

Wenn ich jetzt irgendetwas vergessen hätte einzubinden würde er ja wohl alle drei anmeckern. Mal abgesehen davon, dass es gestern ja dann auch nicht funktioniert hätte.

Ich will jetzt nicht alle 11184 Fehler durchgehen, aber der Kontext ist halt immer wieder, dass es gestern funktionierte, heute nicht.

Welche der beiden Firmen will mich also in den Wahnsinn treiben, Epic oder Microsoft?

Oder gibt es irgendetwas, was ich vielleicht überprüfen kann, es muss ja etwas sein, was vielleicht nicht mit abgespeichert wird.

Also einen Teil der Fehler konnte ich beseitigen. InX usw. wurde nur angezeigt, ich hatte das für die Autovervollständigung gehalten und es in den nächsten Zeilen habe ich es dann händisch mit getippt, weil ich dachte, es gehört dazu. OK, das war dann halt meine Blödheit.

Ändert aber irgendwie nichts daran, dass einige #includes nicht mehr funktionieren, obwohl diese vorher funktioniert haben. Und noch so ein paar andere lustige, oder auch weniger, Fehler. Meistens betreffend in Dateien, die sich gar nicht auf meinen Code beziehen. Also zumindest gehe ich davon aus, weil viele Zusammenhänge kriegt man ja gar nicht so mit, gerade was auch die eigenen Bibliotheken und Makros der UE angeht.

Ja, dabei handelt es sich lediglich um ProcedualMeshCore. Das habe ich eingebunden, und danach habe ich das Projekt mal leer Testcompiliert, da funktionierte noch alles.

Und wie gesagt, nachdem ich den ersten Code geschrieben hatte, ging ja auch noch alles. Erst als ich wieder geladen hatte. Da hat sich ja nun nichts geändert. Das komische ist halt, dass immer andere Fehler auftauchen.

Inzwischen habe ich das #includeproblem gelöst, ich weiß noch nicht einmal warum, weil ich hatte erstmal andere Sachen ausprobiert, zugegeben ein wenig planlos. Einfach mal ; gelöscht und neu gesetzt und plötzlich geht es. Das habe ich aber auch nur gemacht, weil die Autoformatierung komisch aussah, normalerweise formatiert VS ja immer richtig, wenn man das ; setzt.

Ich habe ein wenig das Gefühl, als wenn VS ein wenig hinterherhinkt. Aber auch das dürfte beim Compilieren ja keine Rolle spielen, dann compiliert er halt langsamer, aber dadurch sollten ja keine Fehler auftauchen.

Inzwischen bin ich ja sogar so weit, dass in meinem Code kein Fehler mehr angezeigt wird. Allerdings jede Menge Fehler, die sich auf die Bibliotheken der UE beziehen. Um genau zu sein sogar noch mehr als vorher, 11168 um genau zu sein.

Alle kann ich natürlich hier nicht auflisten, aber ich nehm mal ein paar Beispiele.

Schweregrad Code Beschreibung Projekt Datei Zeile Unterdrückungszustand

Fehler (aktiv) E0894 Überladene Funktion "TVector4" ist keine Vorlage.

Schweregrad Code Beschreibung Projekt Datei Zeile Unterdrückungszustand

Fehler (aktiv) E0719 Änderbar ist nicht zulässig.

Schweregrad Code Beschreibung Projekt Datei Zeile Unterdrückungszustand

Fehler (aktiv) E0065 Es wurde ein ";" erwartet.

Derartige Fehlermeldungen sind halt haufenweise vorhanden. Ich weiß ja, dass es bei C++ nicht so einfach ist. Oftmals liegt der Fehler ganz woanders, als da, wo er angezeigt wird. Aber ich bin heute den ganzen Tag den Code durchgegangen und ich habe keine weiteren Fehler gefunden.

Der Namespace wird ja automatisch erzeugt, ich habe ja nur einen Actor auf C++-Basis hinzugefügt.

Und Copy and Paste habe ich auch nicht benutzt. Alles von Hand getippt. Aber klar, ich habe ich noch gar nicht so viele Zeilen Code geschrieben. Wie gesagt, die Fehlermeldungen beziehen sich alle auf Headerdateien der Unreal Engine, nicht eine einzige bezieht sich auf meinen Code.

Deswegen gehe ich von zwei Möglichkeiten aus. Einmal, dass etwas nicht richtig eingebunden wurde, also Abhängigkeiten irgendwie nicht stimmen, oder ich habe irgendeine Funktion/Methode verwendet, so wie sie nicht vorgesehen ist. Letzteres würde allerdings wiederum zu Fehlermeldungen in meinem Code führen.

Übrigens, wenn ich Code bereinigen mache, zeigt er mir gar keinen Fehler an.

Jetzt bin ich total verwirrt.

Ich versuche gerade das Projekt ein wenig umzustellen. Ich mache jetzt kein reines C++ Projekt daraus, sondern über die BP-Bibliothekt, also eigene Nodes etc.

Jetzt macht er mir eine Fehlermeldung bei einem enum. Ich finde aber keinen Fehler. Die Meldung ist auch sehr verwirrend.

UENUM(Meta = (Bitflags))
enum EDirection {
    Forward,
    Right,
    Back,
    Left,
    Up,
    Down
};

Also nun ja nicht wirklich etwas Besonderes. Wobei ich Meta = (Bitflags) jetzt noch hinzugefügt habe, weil ich im Internet gelesen habe, dass das so gehört. Normalerweise hatte ich da nur ENUM() stehen.

Die Fehlermeldung lautet wie folgt:

Fehler C2365 "Forward": Erneute Definition; vorherige Definition war "Funktion".

Was will der von mir? Die vorherige Definition war zu keinem Zeitpunkt Funktion oder was auch immer.

Der Vollständigkeit halber auch noch die Benutzung von EDirection:

    UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "Chunks|Enums")
        TEnumAsByte<EDirection> Directions;

Ich benötige das auch im Quellcode, weil ich muss mit einigen Funktionen darauf zugreifen. Soll ja auch umgekehrt gehen, von C++ aus auf BP zugreifen, aber ich weiß nicht so recht, ob das so einfach ist.

Und vielleicht sollte ich die Frage gleich hinterher schieben. Ich muss danach noch vergleiche anstellen. Also im BP kann ich ja ein Equal mit Zugriff auf das Enum erstellen, wo ich dann abfragen kann, ob gerade Forward, Up, Down oder was auch immer aktiv ist abfragen. Wie mache ich das in C++?

Ich fasse es kaum. Es funktioniert inzwischen tatsächlich.

Waren wirklich ein paar dusselige Fehler, die ich gemacht habe. Also viele waren dusselig, einge schlicht unlogisch.

Aber es liegt leider doch nicht an der Engine oder an Visual Studio. Ich hätte ja zu gerne die Schuld einem von beiden in die Schuhe geschoben. Aber bedauerlicherweise liegt es dann doch wohl an meiner Wenigkeit.

Puh, jetzt glaube ich allerdings doch wieder, dass da etwas nicht unbedingt stimmt.

Ich habe jetzt alles hinbekommen. Alle Methoden und Funktionen sind programmiert, es wird auch erfolgreich kompiliert, doch wenn ich das Projekt dann wieder im UE-Editor öffnen will, dann stürzt der immer wieder ab. Wenn ich dann sende und neu öffnen klicke stürzt er wieder ab, es ist nicht möglich das Projekt noch einmal zu öffnen.

Langsam bin ich da nervlich am Ende.

Das kann doch nicht wahr sein, dass wenn man mal jenseits von BP sich ein wenig weiter entwickeln will, und ich bin ja bei weitem noch nicht so weit in C++, dass ich da ein verbessertes Far Cry oder so programmiere, also alles kein Hexenwerk, dass dann da so Probleme auftreten, die man gar nicht mehr nachvollziehen kann.

OK, durch die Lösung der Probleme, die ich am Anfang des Themas geschrieben habe, habe ich wirklich eine Menge gelernt. Aber einfach so abstürzen und nicht mehr im UE-Editor öffnen zu können ist einfach nur unfair.

Welches Log hättest du denn gerne? Ich habe da jede Menge.

Einige listen nur die Plugins auf, die beim Compilieren vorhanden waren, da habe ich keine extra aktiviert, außer FastNoiseLite, alle anderen sind Standard in der Engine.

Einige sind absolut kryptisch und unlesbar.

Ich vermute mal, dass es mit ProceduralMeshComponent zu tun hat. Damit hatte ich eigentlich von Anfang an Probleme. Zuerst hat er ja immer #include "ProceduralMeshComponent.h" angemeckert, dass er die Datei nicht finden oder öffnen kann.

Soweit konnte ich mich dann aber im Internet durchforsten und habe irgendwann mitbekommen, dass man in der Project.Build.cs die Zeile PrivateDependencyModuleNames.AddRange(new string[] { "ProceduralMeshComponent" }); ergänzen muss. Das war ja auch das, was du gefragt hattest.

Danach ging es komischerweise mit dem Compilieren ohne Fehlermeldung, mein Mesh-Actor wurde dann aber in der Map nicht so dargestellt, wie ich es wollte. Um genau zu sein wurde gar nichts dargestellt, also als wenn nichts vorhanden war.

Als ich den Code dann kontrolliert habe, ist mir aufgefallen, dass wieder das #include rot unterstrichen war, er meldete, dass er auf die ProceduralMeshComponent.h nicht zugreifen könne. Er compilierte aber ohne Fehlermeldung, was ich schon sehr merkwürdig fand und deswegen hatte ich es wohl auch vorher nicht bemerkt.

Irgendwann habe ich dann gelesen, dass man mit Rechtsklick auf Datei *.uproject die Visual Studie Project Files noch einmal neu erstellen lassen soll. Danach war der Fehler dann auch weg. Aber ich kann es halt nicht mehr ohne Crash im UE-Editor öffnen.

Ich habe jetzt noch einmal alle Logfiles gelöscht, um eben halt die entscheidende zu finden. Ich kopiere sie jetzt mal nicht in voller Länge hier rein, sondern nur den Anfang, wo eben halt etwas von Faild steht. Der Rest scheint nur eine Auflistung verschiedener Dateien und meiner Hardware in Form von Hashtags zu sein.

LogWindows: Failed to load 'aqProf.dll' (GetLastError=126)
LogWindows: File 'aqProf.dll' does not exist
LogProfilingDebugging: Loading WinPixEventRuntime.dll for PIX profiling (from ../../../Engine/Binaries/ThirdParty/Windows/WinPixEventRuntime/x64).
LogWindows: Failed to load 'VtuneApi.dll' (GetLastError=126)
LogWindows: File 'VtuneApi.dll' does not exist
LogWindows: Failed to load 'VtuneApi32e.dll' (GetLastError=126)
LogWindows: File 'VtuneApi32e.dll' does not exist

Kann ich dir auch geben. Sah aber eher unspannend aus. Zumindest auf den ersten Blick.

Ich habe einfach mal den Ordner auf Dropbox gelegt, weil sogar nur das Ende der Datei zu viel ist für einen Beitrag. Ich habe da auch nochmal durchgeschaut und finde da wirklich nichts was verdächtig ist. Muss ich da vielleicht auf etwas bestimmtes achten?

Crashes

Shared with Dropbox

www.dropbox.com

Ja, es könnte durchaus sein, dass es an der Map liegt. Es gibt keine großartige vorherige Version, die ich wieder herstellen könnte. Ich habe eigentlich nur eine Map generiert, und den Actor reingeschoben, den ich dann in C++ programmiert habe. Also viel ist da nicht wieder herzustellen.

Ich wollte halt nur mal herausfinden, wie man Meshes procedural erstellen kann, in diesem Fall sollte optisch erstmal sowas wie die Welt von Minecraft herauskommen, worauf ich dann eventuell weiter aufbauen wollte, bzw. immer noch will.

Ich probiere das mal mit der ini, vielleicht geht es ja, wenn ich den Actor in die Map baue, wenn die Engine bereits geladen ist. Ansonsten wüsste ich absolut nicht, was diesen Crash verursachen könnte, weil ist ja ohne weiteren Error compiliert.

Das mit Laufwerk D ist mir noch gar nicht aufgefallen. Eigentlich hatte ich das Laufwerk als Standardverzeichnis für Epic-Spiele benutzt, die Engine sollte eigentlich auf C: liegen. Aber ich denke mal, dadurch, dass ich im Nachhinein die Version 5 installiert, 4 war wohl noch auf C:, er dann das Laufwerk benutzt hat. Ich habe da halt nicht so dolle drauf geachtet. Kann ich aber ja auch mal ändern.

Danke erstmal.

Es ist völlig irrtierend.

Wenn ich in der Ini das Defaulttemplate lade, startet die Engine, kein Problem.

Ich kann sogar meinen Actor in die Map packen, nichts passiert. Aber sobald ich im Editor die Game_Map laden will, wieder Absturz, so weit, so gut.

Aber, jetzt kommt es. Selbst wenn ich die Game_Map gar nicht lade, nur wenn ich mit rechter Maustaste darauf klicke, um diese zu löschen, es kommt nicht einmal das Auswahlmenü, crasht die Engine wieder.

Ich musste die Map per Windows-Explorer aus dem Projekt löschen.

Das kann ja nicht so richtig sein, oder?

Ich habe sie mal neu angelegt und den Actor reingehauen. Funktionierte, nur der Actor wurde nicht dargestellt. Nichts passierte, weder im Editor, noch im Testbetrieb. Build hatte ich auch neu ausgeführt, daran kann es also nicht liegen. Dann habe ich es in VS noch einmal compiliert, bums, dasselbe Problem wie vorher.

Ich werde noch einmal Zeile für Zeile durchgehen. Auch wenn er keinen Fehler anzeigt, irgendwo muss ja etwas zu finden sein.