GS FileViewer Feedback und Wünsche

Danke für die Änderung.

Ich habe das Problem, dass, wenn ich versuche die Dateien aus dem Ordner des Download Dortmund Modifikationen mit dem GS-Viewer zu extrahieren, eine Fehlermeldung ( Fehler in Zeile xxx) auftaucht, sokann ich die Modifikationen folglich nicht nutzen.

Im voraus schon mal vielen Dank für die Hilfe.

Willkommen im Forum.

Soweit ich sehen kann, gibt es dort keine gs-Datei, die man extrahieren müsste. Ansonsten versuchst du, eine andere gs-Datei (anderer Mod) zu öffnen.

Danke,
aber das hilft m,ir jetzt noch nicht, da ich die Dateien nun auch nicht, wie in der Readme beschrieben einordenen kann, da ich gar nicht in metro.gs und objects.gs rein komme.

Dann musst du aber schreiben, dass du die Standard gs-Dateien nicht öffnen kannst.

Dann probier mal folgendes:
Klicke mit der rechten Maustaste auf die gs-Datei und dann auf "öffnen mit ...". Dann suchst du den gs-Entpacker und wählst ihn aus. Dann sollte es klappen.

Hello.
Needed to download and use the GS File Viewer to edit saved game data to get past bug in the American campaign, San Francisco map... Quake Prevention task. Irrelevant information, I know.

At any rate, after installation, opening the saved game file, and extracting it all to a separate folder, I get this error upon attempting to edit the location (gamedata.script)...
GS_File_Viewer_Error_1.jpg
Galerie - Cities in Motion - Fanpage
It is important to note that the installation MSI file was run from a location on the C drive, the game is run from Steam installed on the C drive, the saved games are all in the default location on the C drive... and I most definitely do not have any directories named "Entwicklung" on my D drive. Also, nothing included with MS .NET 2.0 would install to a D drive in a directory called "Entwicklung"... as this would pose issues with those people who lacked a second hard drive or partition.

Any thoughts here?

Your Operation System says GS Viewer it can't open the file because there is no application handling this type, but GS Viewer doesn't know to handle this error. So it crashes and shows a dump what routines in what source files generated the error. (So the dev know where to look at, so not your filesystem, but it shows the paths on the build maschine)

Create a new file "dummy.script", double click on it and tell Windows to use Wordpad with script files. Then when you use GS Viewer shouldn't crash anymore

Wordpad? Don't you mean Notepad? I mean, I can most certainly tell Windows to start Wordpad whenever a .script file is called, but I just want to be clear, since Wordpad and Notepad are two different programs, and Wordpad will tack additional data onto a file that Notepad will not. For that matter, if you meant to say Notepad, I could just as easily tell Windows to attach Notepad++ to .script files, as it is a more powerful editor. I just need you to be clear on the advice you are giving me, before I take a corrective step that will be much more complicated to UNDO, should you have meant something else... or should the developer decide that he can fix the issue with a small bug release.

Which brings up another point, about how the installer (MSI) should take care of creating these extension dependencies? I mean, seriously... what's the point of an automated installation program that leaves the job half done?

And it isn't *just* that my OS doesn't have a program already set to handle the .script files.... GS File Viewer is attempting to reference a SPECIFIC location that HAS to be hard coded into the program...
D:\Entwicklung\GSFile\
... as there is absolutely nothing even remotely similar on my computer. Where did my computer get this file location from, if it wasn't coded into the program? Why is the program referencing some odd location on my D drive, when the program itself was installed from the C drive, is installed *to* the C drive, works to edit a game installed on the C drive, and edits files that are located on the C drive?

Entwicklung means Development... as in the software designer has the program in a directory named "Entwicklung", and references to that directory structure are left within this version of the program.... which should *NOT* be the case.

The first line and error message is the real reason it crashes, then follows a C# stack dump. If you compile your application with Debug info you get pretty lines numbers with all paths. Don't believe me? Reread the stack dump you posted in the screen shot and see there are line numbers mentioned with each .cs file? cs files aren't executable but are the source code for c# applications.

You can read the source code here btw:
SourceForge.net Repository - [gsfileviewer] Index of /

Wordpad supports unicode + reads non dos line endings too. You don't want a text soup.
Yes you can use any editor you like that reads unicode and can work with non-dos line endings.

You should think about the tone of your next posts, otherwise I will ignore you the next time.

And no, I am not the author of GSFileViewer.

Hallo liechti

Ich finde es sehr gut, das man seit Version 1.6 auch eigene Dateien hinzufügen kann.
Genial wäre es, wenn dein Programm anhand der Dateiendung schonmal einen passenden "File type" vorauswählen könnte. Könntest du soetwas mit einbauen?

Ach ja: Kann man den Basispfad in selbsterstellen .gs - Dateien irgendwie eingeben? oder auch ändern?

Vielleicht wenn ich mal Zeit habe, könnte ich mein gs_compress herausbringen, das muss ich aber noch ein bisl aufpolieren. Das kann die gewünschten Sachen.

liechti:

Alle Dateien die ich bis jetzt getestet habe, ist das was Du als Type bezeichnest, einfach die ersten 4 unkomprimierten Bytes.

#define FILETYPE_GS_ARCHIVE	0x30315347  // 'GS10'
#define CHUNK_GS_ARCHIVE	0x01000000
#define CHUNK_FILE_INDEX	0x01100000
#define CHUNK_FILE_ENTRY	0x01120000
#define CHUNK_FILE_BASEPATH     0x01130000
#define CHUNK_PACKED_DATA	0x01200000


struct gs_file_entry {
    uint32_t signature;
    uint32_t offset;	// relative to the start of CHUNK_GS_ARCHIVE data
    uint32_t size_unpacked;
    uint32_t size_packed;
    char name[128];
} __attribute__((packed));


signature = 4 bytes der unkomprimierten Datei

Keine Ahnung warum Du einen Type überhaupt vom Benutzer wissen möchtest, das sind einfach die ersten 4 Bytes der nicht gepackten Datei.

Zitat von eis_os

Alle Dateien die ich bis jetzt getestet habe, ist das was Du als Type bezeichnest, einfach die ersten 4 unkomprimierten Bytes.

Denke auch, daß das nur die ersten 4 Bytes sind. Liechti bezeichnet das in seinem Programm als "File typ" und will den dann manuell zugeordnet haben. Da man über den FileViewer nur ASCII - Zeichensatz eingeben kann, hab ich bisher versucht, das mit einem Hexeditor zu korrigieren. Was aber bei großen Dateimengen umständlich ist. Das Drag and Drop ist mir zu umständlich, da ich dann auch jede Datei wieder ins richtige Verzeichnis schieben muss. Die Funktion hab ich schon entdeckt.

eis_os: bin schon gespannt auf dein gs_compress. könnte ich gut gebrauchen^^

Zitat von liechti

Nun wäre nur die Frage ist das Feature dringend gewünscht mit dem Mehrfachimport und was soll er genau können. Alle Dateien vom Ordner in den momentan selektierten Ordner ablegen?

Diese Variante würde ich bevorzugen. Am einfachsten ist das sicherlich so umzusetzen, das man anstatt einer Datei auch einen Ordner anwählen kann und dein Programm einfach die enthaltenen Ordner und Dateien selbständig hinzufügt.

Wenn du mehr zeit hast kannst du das natürlich auch wie bei einem packprogramm machen (winrar oder ähnliche). Also mit Möglichkeit Dateien auch zu verschieben. Das ist aber nicht so wichtig. Hauptsache die GS-Datei wird fehlerfrei geschrieben

Ich hab noch einen "Fehler" entdeckt:
Byte 18 setzt dein Programm immer auf 13. Auch wenn vorhandene GS-Dateien bearbeitet werden. Das führt dazu das CiM die Dateien nicht mehr einliest. Hab zwar keine Ahnung was dort kodiert wird aber beim Vergleichen mit anderen Dateien bin ich darauf gekommen das das Byte in manchen Fällen auch den Wert 14 hat. Dann erkennt es CiM auch. Möglicherweise hilft dir da der Anfang vom Quellcode von eis_os weiter. Bei den Fahrzeug-Addons scheint der Wert 13 zu sein, bei den restlichen 14. Kann auch mit der Ordnertiefe zu tun haben....

Ich hoffe ich hab etwas weiter geholfen.
Gruß medi

Welche Datei hat da 14?
Kannst Du bitte ein Hex Dump Posten und den Namen der GS Datei?

PS: Leider ist zlib nicht statisch gelinkt, muss die gs_compress noch ein bisl anpassen.