Umfrage: Sollen pak-Dateien zusammengepackt werden?
dafür
7.41%
2 7.41%
dagegen
59.26%
16 59.26%
teilweise
33.33%
9 33.33%
egal
0%
0 0%
Gesamt 27 Stimme(n) 100%
∗ Du hast diese Antwort gewählt. [Zeige Ergebnisse]

Themabewertung:
  • 0 Bewertung(en) - 0 im Durchschnitt
  • 1
  • 2
  • 3
  • 4
  • 5
Zusammenpacken von Pak-Dateien
#1
Zitat:Original von DirrrtyDirk
...
Zitat:Original von FrankP
Und letztlich ist das der Nachteil, wenn man die Fahrzeugdateien in eine Datei zusammen packt.
[...]
Ehrlich gesagt verstehe ich nicht ganz was das in diesem Fall ändern sollte.
Das ist doch eher eine Frage von Dateigröße und der damit verbundenen nötigen Übertragungszeit für Korrekturen (sprich Komfort für den Nutzer), ob man jetzt nur eine kleine Datei austauscht oder eine komplette vehicle.all.pak (oder wie auch immer die letztenendes dann heisst). Ändern und korrigieren kann man in beiden Fällen. Und es wirft immer noch die gleichen Probleme auf. Nur in einem Fall wäre(n) die Datei(en) eben nur einige KB groß, im anderen leider einige MB. Das ist also eher eine Grundsatzfrage, die aber mit dem Problem hier meiner Meinung nach nicht direkt verbunden ist.

Nun, dann diskutieren wir das mal etwas ausführlicher.

Für die "Schreibfaulen" eine Klickumfarge dazu.

Wenn man das Argument Dateigröße und Download vorbringt, dasnn eine kleine Rechnung.

Pro Datei spart das zusammenpacken ca 38 kByte ( soviel wars wohl glaub ich ) ein.

Bei pak128 werden aber 3,6 Megabyte Compatibility-Dateien mit dazu gepackt. Das ist "Dateimüll"-der zum Teil über 2 Jahre alt ist und deshalb kaum noch zum aktuellen Set passt.

Davon abgesehen, das Neueinsteiger diese 3,6 MByte überhaupt nicht brauchen.

Bei der Download-Größe dürfte das zusammen Packen kaum eine Rolle spielen, da die Pak-Dateien sehr gut komprimiert werden.

Wenn man Datenvolumen sparen will, dann muss man die Grafiken optimieren. Da kann man richtig sparen. Und das wirkt sich dann auch auf die Rechnerauslastung aus.

Beispiele
Zitat: - optimizing graphics and animation factory Moebelhaus (a0-homemarket-128.png, factories-wood-128.dat); pak file size 3 MB -> 410 kB (FrankP)
- fix and optimizing grafics and animation factory Materialswholesale (a0-materialswholesale-128.png, factories-material-128.dat); pak file size 777 kB -> 81 kB (FrankP)
- optimizing grafics and animation factory Sandquarry (a0-Sandquarry-128.png, factories-material-128.dat); pak file size 393 kB -> 145 kB (FrankP)
__________________________________________

Bei Einzeldateien fischt man sich die benötigten Dateien einfach aus dem alten Ordner/Archiv.

Für den IC2000 heist das, 2 Datei aus dem alten Ordner rüber kopieren.
Nämlich die für den angetriebenen Steuerwagen und die für den Wagen.
Werden alle Wagen die zum IC2000 gehöhren zusammengepackt, dann reicht das kopieren von einer Datei.

Bei einer zusammengepackten Datei mit vielen Fahrzeugen, muss man erst die alte und die neue Version der Datei zerlegen und dann die Dateien rüber kopieren. Und das dann bei jeder neuen Version.

Die zusammengepackte Datei zerlegen muss auch jeder, der aus dem mitgelieferten Fuhrpark was ersetzen/entfernen möchte.

Ein Punkt kommt nämlich auch noch dazu. Die zusammengepackten Dateien lassen sich mitunter nicht zerlegen.

Ein weiterer Punkt ist, das man nicht einfach erkennen kann, ob es eine Datei schon gibt. Bei Einzeldateien wird beim kopieren gemeckert, wenns eine Datei gleichen Namens gibt.
Zitieren
#2
Ich spreche mal "nur" für pak96.comic. Und bin von daher ganz dagegen.

1. Würde ich selbst schneller den Überblick verlieren und
2. Ich finde zusammengepackte Datein Userunfreundlich denn
2a fehlerhafte Dateien können entfernt werden
2b wenn der Spieler die Warenpreise nicht gut findet kann er diese recht leicht neu erstellen (da keine Grafik benötigt wird)
2c wenn der Sieler findet Objekte sind nicht hübsch kann er sie löschen
2d wenn er ein Objekt erstetzen möchte durch z.B. ein eigenes ist das recht leicht möglich
Zitieren
#3
In allen meinen Projekten haben sich große Datenklumpen als eher Problematisch erwiesen, wenn es um Fragen wie Wartbarkeit oder Erweiterbarkeit ging. Das Laden vieler kleiner Dateien ist langsam, das kann auch ein problem sein (nicht für Simutrans denke ich), und es ist schwere den Überblick zu behalten, aber es scheitn für Projekte die offen und erweiterbar sein wollen der bessere Weg zu sein.

Selsbt die PAK Dateien an sich sind schon eine Mitmach-Bremse, ofte wäre es für die Leute einfacher wenn die PNGs und DATs offen vorliergen würden - vielleicht ist MakeObj aber auch genau die richtige Einstiegshürde, das ist schwer zu sagen.

Ich bin für kleine/einzelene Dateien aus Sicht der Erweiterbarkeit udn Wartbarkeit.
Blogger blog blog
Zitieren
#4
Meine Meinung:

1.) Ich finde das PAK-Datein eigentlich nicht zusaamen gepackt gehören. (Stimme sojo eigentlich alles zu was er gesagt hat.)

2.) Möchte aber noch etwas anfügen:
Um die Erweiterbarkeit/Ausstauschbarkeit, finde ich es dennoch gut, wenn man PAKs die Zusammengehören (z.B.: Triebzüge, symbol.*.pak, ...) zusammengepackt gehören, denn alleine nutzen die einem ja sowieso nichts!
Und wenn man es löschen will (z.B.: Triebzug), kann man dann auch keine Datei vergessen.
3.) Systemobjekte gehören gepackt, denn dort sollte meisten nichts verändert werden, und wenn doch gibt es ja "EXTRACT".
Dies macht den PAK-Set Ordner auch um einiges übersichtlicher.

Ist nur meine Meinung...
Ex-Entwickler und Gründer des pak192.comic, Betreiber von Simutrans Hosting
Zitieren
#5
Zitat:Original von Hajo
Das Laden vieler kleiner Dateien ist langsam, das kann auch ein problem sein
Das trifft nicht immer zu. Als ich mal einen Test zum packen machte hatte ich einmal große PNGs mit vielen Bildern vom pak.german und "meine" Vorgehensweise beim pak96.comic, mit fast für jedes Objekt eine extra PNG.

Ich weiß nicht mehr wie groß der Unterschied war. Aber pak96.comic hatte erhebliche Geschwindigkeitsvorteile beim packen.
Zitieren
#6
Das dürfte eher an der Verarbeitung in MakeObj liegen. Filesystemtechnisch gewinnen große Dateien, irgendwie scheint das Öffnen einer Datei für manche Betriebssysteme aufwändig zu sein.

Simutrans liest die vielen PAK Dateien aber sehr flott, somit scheint es nicht wirklich ein Problem zu sein.
Blogger blog blog
Zitieren
#7
Ich persönlich sehe das ganz ähnlich wie Cruzer: ein Mittelweg ist meiner Meinung nach das beste. Für jedes einzelne noch so kleine Objekt eine einzelne Datei zu haben finde ich genauso wenig erstrebenswert wie alles in eine einzige große Datei zu packen.

Auch habe ich beim Testen und Probieren mit selbst gepakten pak128 Versionen festgestellt, das sich mein Computer beim kopieren/verschieben des Paksets deutlich schwerer getan hat wenn da hunderte von einzelnen Fahrzeug-Paks drin waren, als wenn diese zu einer großen Datei zusammengefasst waren. Aber das sind natürlich wieder die beiden Extremfälle miteinander verglichen. Beides hat Vor- und Nachteile - denn wie wir alle von Lord Helmchen aus Spaceballs wissen: jeder Saft hat zwei Seiten. Wink Ich bleibe dabei: ein gesunder Mittelweg dürfte das beste sein.

Aber ehrlich gesagt ist es - zumindest im Bezug auf pak128 (und darum geht es ja letzten Endes wohl hauptsächlich - es war zumindest der Stein des Anstosses) - ziemlich müssig, das hier und ohne VS zu diskutieren.
Zitieren
#8
Zitat:Original von DirrrtyDirk
Aber ehrlich gesagt ist es - zumindest im Bezug auf pak128 (und darum geht es ja letzten Endes wohl hauptsächlich - es war zumindest der Stein des Anstosses) - ziemlich müssig, das hier und ohne VS zu diskutieren.
Das stimmt. Nur sehe ich die Diskussion etwas allgemeiner. Sollte bei so einer Diskussion herauskommen, das große Datein besser sind werde ich pak96.comic anpassen.

Daher ist dieser Thread wichtig, weil er anderen Paksetentwicklern helfen kann.
Zitieren
#9
Ich bin aus den bereits genannten Gründen auch dagegen.

Viele kleine Dateien sind beim Entpacken sicherlich langsamer, als wenige große. Jede Datei wird ja einzeln eingelesen, da macht es natürlich einen zeitlichen Unterschied ob nur 10 oder eben 1000 sind. Aber der Fall tritt ja nur bei der Installation und leicht beim Start vom Pakset auf, und nicht beim Spielen selber. Dafür ist die Möglichkeit die einzelnen pak's zu bearbeiten ein deutlicher Vorteil. Das dürfte vorallem die Pakset Ersteller betreffen, aber auch einen Teil der User.
Zitieren
#10
Zitat:Original von DirrrtyDirk
....
Aber ehrlich gesagt ist es - zumindest im Bezug auf pak128 (und darum geht es ja letzten Endes wohl hauptsächlich - es war zumindest der Stein des Anstosses) - ziemlich müssig, das hier und ohne VS zu diskutieren.

Der Bezug in diesem Thread war die 'Grundsatzentscheidung', die Du angesprochen hast.
Das betrifft nämlich auch pak128.britain, pak.abo und pak.contrast.

Ausserdem lesen Leute aus dem int. Forum hier durchaus auch mit, auch wenn sie nicht registriert sind.
Und diese Diskussion auch im int. Forum anzustoßen, daran hindert keiner. Wobei es diese Diskussion schon mal in Bezug aufs pak128 vor etwa 2 Jahren gab. Da nämlich, wo es die ganzen 1.2.9er Versionen in kurzen Abständen gab.

zum pak.german
Beim pak.german gibs ein teilweises zusammenpacken.

Smoke und Good werden nicht zusammen gepackt, was Eigenentwicklungen erschweren würde. Vor allem steht im Wiki an einigen Stellen, das als Parameterwert die entsprechenden Pak-Dateinamen gelten. Die erfährt man logischerweise nicht so einfach, wenn alles zusammen gepackt wurde.

Bestes Beispiel war dafür, das die Buecher im pak128 Bucher hiesen oder noch immer so heisen.
_________________________________________

Zitat:Original von FrankP
... Pro Datei spart das zusammenpacken ca 38 kByte ( soviel wars wohl glaub ich ) ein.
....

Sind sogar nur um die 38 Bytes.
Zitieren


Gehe zu:


Benutzer, die gerade dieses Thema anschauen: 1 Gast/Gäste