Deine Anzeige (bzw. generell dein Programm?) dekodiert die Dateien falsch, das ist ANSI bzw. Latin1, kein UTF8. Deswegen hast du da ein Fragezeichen statt 'ä'. Da solltest du beim Zurückschreiben drauf achten, denn der Parser kommt mit UTF8 nicht zurecht.
Danke für den Hinweis, beim Speichern muss Ich das demnach unbedingt angeben.
Ich habe das Encoding Latin1 bei mir als Globales Encoding festgelegt. Bisher habe Ich ASCII verwendet.
Für den Pfad bitte einen "Öffnen" Dialog einbauen, um ihn auszuwählen zu können. Die Option, ihn direkt einzutippen kann auch praktisch sein, aber ein Auswahlfenster ist eigentlich Standard.
Vielleicht kannst du beim "Laden" auch anzeigen lassen, was er gerade macht? Bei mir sitzt er eine halbe Ewigkeit bei einem bestimmten Fortschritts-Level (siehe Anhang)
Vielleicht kannst du beim "Laden" auch anzeigen lassen, was er gerade macht?
Klar kann Ich
Das initiale laden des Dateibaumes kann schon mal einen Moment dauern. Danach gibt es noch ne Kleinigkeit, wo er ansteht bevor Ich die Instanzen alle Inizialisieren kann.
E: Für die Pfadauswahl habe Ich auch mal Buttons eingefügt. Ich glaube aber, das der Standard Windows Dialog richtige Sch**** ist, und werde bei gelegenheit mal nach einem besseren GUI suchen.
Klar kann Ich
Das initiale laden des Dateibaumes kann schon mal einen Moment dauern. Danach gibt es noch ne Kleinigkeit, wo er ansteht bevor Ich die Instanzen alle Inizialisieren kann.
Bei mir hat sich in einer halben Stunde nichts getan (gleichbleibend volle CPU-Auslastung eines Kerns). Der Fortschrittsbalken kommt so weit, wie auf meinem kleinen Bild gezeigt (vorheriger Beitrag), aber nicht weiter. Irgendwann habe ich das Programm dann beendet, ohne dass es mir etwas angezeigt hat.
Wenn es teils recht lange dauert, die Skripte zu laden, wäre es eventuell auch schön, die Übersicht abspeichern zu können, damit die bereits gemachten Analysen des Programms schneller aufgerufen werden können, ohne die Skripte bei jedem Programmstart neu laden zu müssen.
--
Vielleicht lässt sich der "Validieren" Button auch ausgrauen, bevor man etwas geladen hat? Der scheint ja nur bei bereits geladenen Skripten etwas zu tun?
Bei mir hat sich in einer halben Stunde nichts getan (gleichbleibend volle CPU-Auslastung eines Kerns). Der Fortschrittsbalken kommt so weit, wie auf meinem kleinen Bild gezeigt (vorheriger Beitrag), aber nicht weiter. Irgendwann habe ich das Programm dann beendet, ohne dass es mir etwas angezeigt hat.
Ne, so lange sollte das nicht dauern. Wir reden da eigentlich von so 20-30s bei ner normalen SSD und dem Orginalspiel.
Hast du es schon versucht später nochmals zu starten?
bzw. schau mal in den Einstellungen nacht, ob da der Autoload eingeschaltet ist. Ansonsten: ein/bzw. ausschalten und nochmals probieren
Ich hatte Version 0.1 verwendet, wieso auch immer.
Mit Version 0.2 stürzt das Programm beim Laden immer ab. Zuerst geht der Balken bis ca. 4/5, dann springt er zurück auf etwa 1/5 und nach etwa einer Sekunde ist das Programm-Fenster dann weg (Prozess taucht auch im Task Manager nicht mehr auf).
Autoload ist ausgeschaltet. Wenn ich es einschalte, dann kommt der Absturz direkt nach Programmstart.
Ich hatte Version 0.1 verwendet, wieso auch immer.
Mit Version 0.2 stürzt das Programm beim Laden immer ab. Zuerst geht der Balken bis ca. 4/5, dann springt er zurück auf etwa 1/5 und nach etwa einer Sekunde ist das Programm-Fenster dann weg (Prozess taucht auch im Task Manager nicht mehr auf).
Autoload ist ausgeschaltet. Wenn ich es einschalte, dann kommt der Absturz direkt nach Programmstart.
Ok, es gibt mMn zwei möglichkeiten:
Problem mit der Threaddistribution
Keine Rechte auf dem Ordner
Für ersteres habe Ich meine Threading DLL ausgemustert, und auf Task und Async umgestellt.
Ausserdem habe Ich ein Log angefügt, welches nach dem Absturz einige Informationen beinhalten sollte.
(Log.xml im DB Ordner)
<root>
<Log>
<Id>710f3d26-cb9e-42e3-9cdb-ae4b798ab7d1</Id>
<Message>Laden der Dateien angefangen</Message>
<TimeStamp>15.11.2018 21:18:43</TimeStamp>
</Log>
<Log>
<Id>88797ffc-1348-42b2-8e40-103f6aadbd24</Id>
<Message>Fehler in einem Non-UI Thread Ein ItemsControl ist nicht konsistent mit seiner Elementquelle.
Weitere Informationen finden Sie in der inneren Ausnahme.</Message>
<TimeStamp>15.11.2018 21:24:20</TimeStamp>
</Log>
</root>
Sehr viel detailliertes Logging wäre evt. hilfreich, einfach damit man sehen kann was das Programm gerade genau macht/versucht.
Auch sollten die meißten UI Elemente ausgegraut sein wenn gerade geladen wird.
Für ersteres habe Ich meine Threading DLL ausgemustert, und auf Task und Async umgestellt.
Ausserdem habe Ich ein Log angefügt, welches nach dem Absturz einige Informationen beinhalten sollte.
(Log.xml im DB Ordner)
Dasselbe Problem tritt bei mir ebenfalls auf. CPU-Auslastung zu dem Zeitpunkt ist gering / nicht vorhanden, das Programm scheint also nicht eifrig etwas zu analysieren, sondern irgendwo im Nichts zu hängen.
Allerdings erscheint mir der RAM-Verbrauch bei 1GB recht hoch? Zu Programmstart sind es nur 17MB, und mein Skript-Ordner ist 77MB groß. Da scheint sich das Programm also noch deutlich größere Datenstrukturen zu erstellen?
Ok, Ich mache mal nen weiteren versuch.
Ich habe das Log im bereich der Instanzenanalyse aufgebohrt. Sobald die Analyse irgendwo feststeckt, wird Sekündlich ein Log geschrieben
Was die Grösse angeht: Ja, 1GB ist durchaus realistisch für eine Mod mit viel Script.
Ich baue aktuell 8 verschiedene Indexes auf, während dem Laden der Daten. Und beim Instanzieren nochmals je einen weiteren.
Ein grosser Teil dürfte aber auf die Kompilierten Daten aus dem ANTLR Parser zurückfallen.
Im Log werden nun auch ANTLR Fehler aufgelistet. Eventuell ist eine Datei kaputt, oder es gab einen Kreisverweis(wie in odyssee beim setzen der NPC Daten).
Was macht eigentlich die Zeile:
Code:
return <?>;
Die ist mir in Odyssee aufgefallen, da Sie mir den Deadalus Compiler beendet.
<root>
<Log>
<Id>8c38e3b2-15ec-4679-b795-fdbce90c284c</Id>
<Message>Fehler in einem Non-UI Thread Die Datei oder Assembly "Antlr4.Runtime.Standard, Version=4.7.1.0, Culture=neutral, PublicKeyToken=e78b2c5abd1fcb3f" oder eine Abhängigkeit davon wurde nicht gefunden. Das System kann die angegebene Datei nicht finden.</Message>
<TimeStamp>17.11.2018 12:17:15</TimeStamp>
</Log>
<Log>
<Id>2a1a796b-8977-4c4b-8015-fd40665aeb55</Id>
<Message>Fehler in einem Non-UI Thread Die Datei oder Assembly "Antlr4.Runtime.Standard, Version=4.7.1.0, Culture=neutral, PublicKeyToken=e78b2c5abd1fcb3f" oder eine Abhängigkeit davon wurde nicht gefunden. Das System kann die angegebene Datei nicht finden.</Message>
<TimeStamp>17.11.2018 12:17:30</TimeStamp>
</Log>
</root>
Man sieht hier auch das das Log nicht neu erstellt wird beim starten, das waren zwei unterschiedliche Startversuche.
Zitat von Multithread
Was macht eigentlich die Zeile:
Code:
return <?>;
Die ist mir in Odyssee aufgefallen, da Sie mir den Deadalus Compiler beendet.
Das sehe ich zum ersten mal, kann mir nicht vorstellen das das gültiges daedalus ist. Hast du da einen größeren Ausschnitt, evt. die ganze Funktion?
Kopf-> Tisch.
Irgendwie habe Ich es fertig gebracht die Antlr DLL nicht mitzunehmen. Die könnt Ihr sonst aus 0.2.5 nehmen.
Die nächste Version wird 0.3 sein, wenn Ich das mit der Versionierung dann mal richtig Hinbekommen
Diese sollte das Erstellen und Bearbeiten von Items bieten.
Dieses merkwürdige Return befindet sich in der Kompilierten Version von Odyssee 2.5.1
Und ist die Ursache, wieso Ich es nicht Kompilieren konnte.
PermMem_Structs.d bin ich mir ziemlich sicher das wir die unveränderte LeGo Version benutzen.
Zitat von Multithread
Dieses merkwürdige Return befindet sich in der Kompilierten Version von Odyssee 2.5.1
Und ist die Ursache, wieso Ich es nicht Kompilieren konnte.
Meinst du dekompilierte Skripte? oder die .dat?
Wenn das in dekompilierten Skripten so steht ist da beim dekompilieren wahrscheinlich ein Fehler gemacht worden.
In der PemMem_Structs.d macht vielleicht die leere Klasse ein Problem? Das gibt es sonst - meines Wissens - in keinem anderen Script in Gothic (macht nämlich auch nicht viel Sinn). Der Eintrag ist aber sowieso obsolet, die wurde für einen Workaround benötigt, der mittlerweile richtig behoben ist. Ansonsten fallen mir nur die Instanzen ein, die mit einem primitiven Typnamen beginnen (instance string@(_string); zum Beispiel), aber das würde mich schon viel eher wundern.
PermMem_Structs.d bin ich mir ziemlich sicher das wir die unveränderte LeGo Version benutzen.
Ok, danke.
Ich werde mir das anschauen, was der DeadalusParser da für einen Fehler meldet.
Das Problem, wieso es aber stecken bleibt (Das Laden nicht abschliessen kann), ist die Instanz:
None_962_BeliarSkeleton.
Um diese wäre Ich ebenfalls froh, eventuell ist da noch ein Problem mit meinem Parser (dieser Ignoriert aktuell IF's beim Instanz laden).
Eventuell muss ich da aber eh über die Einstellungen das Einstellen von benötigten Variablen und Konstanten erlauben.
Ich muss mir da was überlegen, wie Ich verhindern kann, das in solch einem Fall alles Stehen bleibt.
EDIT:
@Lehona:
Nein, das problem mit den Structs ist folgendes:
Code:
instance zCList__zCViewText@(zCList__zCViewText);
Ich habe leider keine Ahnung ob das gültiger Code ist.
EDIT2: Ich glaube sogar, er hat ein Problem mit dem Endline der entsprechenden Datei. Ich kann es drehen und wenden wie Ich will: Beim letzten Zeichen wirft er eine Fehlermeldung.
Tut mir zum glück nicht weh.
Die anderen Beiden Dateien spricht er bei mir nicht an, bezüglich der Fehlermeldungen.
World of Players
[Tool] Gothic Script analyzer
Zitat von Milky-Way
![[Bild: ItemList_Preview.png]](https://upload.worldofplayers.de/files11/ItemList_Preview.png){kind=link}
![[Bild: AMD_Threadripper.png]](https://upload.worldofplayers.de/files10/AMD_Threadripper.png){kind=link}
![[Bild: i6tfHoa3ooSEraFH63.png]](https://upload.worldofplayers.de/files10/i6tfHoa3ooSEraFH63.png){kind=link}
![[Bild: sigpic135681_7.gif]](http://forum.worldofplayers.de/forum/signaturepics/sigpic135681_7.gif){kind=link}
![[Bild: ProgressBar_Info.png]](https://upload.worldofplayers.de/files11/ProgressBar_Info.png){kind=link}