Fragen zu makeobj

[RHBaum]

Mal ne andere Frage:

haben die Paks eine eigene Format version ?
Wenn ja wird diese von simutrans ausgewertet ?
wenn nein, wuerde das viel arbeit machen ? und ist in den Paks da platz (metadaten) ?

Glaub das wuerde der benutzbarkeit enorm helfen, wenn simutrans selber weiss, welches Format es erwartet und unterstuetzt, und man makeobj evtl dahingehend erweitern koennte, das es bestimmte(mehrere) versionen unterstuetzt.

Neuprogrammierung mit (eventuell Window-Oberfläche) würde noch mehr Probleme mit der (Aufwärts-)kompatibiltät erzeugen.

Aufwaertskompatiblitaet in dem Sinne gibts ja ned, ansonsten wuerd ich ins kristallkugelgeschaeft einsteigen ^^
Aber das Format von der eigentlichen programmversion zu trennen wuerde schon gehen ... Wenn mans richtig macht, braeuchte man dann keine Liste von Simutrans versionen die zu makeobj version kompatibel sind, sondern die programme wuerden selber bestimmen, welche formate sie erzeugen/unterstuetzen ...

Ne windows oberflaeche waer fuer viele scho recht praktisch ^^

Ich koennt mir aber auch vorstellen, das man den "zusammenbau" eines Paks aus den einzelnen komponenten (dat und png und was weiss ich, und natuerlich version infos) in einer projectdatei(vielleicht xml) beschreibt, und ein makeobj damit beschiesst .... was einem dann die pak erstellt.
Zu dem der projectdatei kann man dann getrennt ne grafische oberflaeche bauen ....
So wuerde es ne saubere Loesung geben, glaub ich ...

Ciao ...

[Hajo]

Original von RHBaum
haben die Paks eine eigene Format version ?
Wenn ja wird diese von simutrans ausgewertet ?

Kann dies nur mit meinem relativ alten Kenntnisstand beantworten:

Ja und ja.

Etwas ausführlicher:

PAKs hatten ursprünglich keine Versionierung. Ich habe das damals für einige PAK Typen eingeführt, und versucht Simutrans so zu bauen, dass Kompatibiliätschecks möglich wurden - ich gehe davon aus, dass Prissi das weiter vervollständigt und angepasst hat.

Alerdings gab und gibt es immer wieder Änderungen die nicht kompatibel zu bekommen sind, auch mit viel Mühe nicht. Das dürften allerdings nicht allzu viele sein.

Um alte PAK Formate zu erzeugen kann man immer ein altes MakeObj benutzen, das ist einfach (der Sinn erschliesst sich mir aber nicht ganz).

Deine gewünschte XML Datei ist für MakeObj wohl das DAT. Zumindest wüsste ich nicht was man sonst in das XML schreiben würde als was heute in der DAT steht.

Original von RHBaum
Ne windows oberflaeche waer fuer viele scho recht praktisch ^^

Wenn Du das gerne programmieren möchtest, nur zu.

[wernieman]

kann man den von außen sehen, welche Versionierung ein PAK hat?

Simutrans selber zeigt es ja nicht an ...

[prissi]

Simutrans zeigt es an. Steht beim laden bei fast jedem Objekt. Fahrzeuge sind z.B. in Version 9, Tunnel in Version 1 (oder 2?) und so weiter. Die Versionen sind dabei keiner Simutrans-Version zugeordnet sondern je nach notwendigkeit schaltet sich ein Subformat weiter.

[RHBaum]

Ja und ja.

Das ist doch schon mal was ...
Dann wird simutrans doch auch nur Paks laden, die kompatibel sind !

Ich hab noch bissi Probleme mit der Namensklomentatur.

Ne Pak-datei iss doch nen "Kompilat" aus bildern und informationen
pak128.german z.b. ist aber dann nen Grafikset, oder ???
und so ein grafikset hat eine Sammlung von pak dateien die es verwendet.

Wenn eine versionsnummer in einem der paks zu nem Grafikset ned stimmt, lehnt simutrans das laden des paks dann ab ?

Um alte PAK Formate zu erzeugen kann man immer ein altes MakeObj benutzen, das ist einfach (der Sinn erschliesst sich mir aber nicht ganz).

eigentlich sollte es sinnfrei sein. Aber scheinbar gibts ja ab und an komplikationen. So wie ich es versteh wurde ja explizit danach gefragt. (selber zu bestimmen welche version). Wahrscheinlich nutzen nicht alle, warum auch immer, die neuste simutrans version, wollen aber doch das aktuelle pak / Grafikset nutzen. Wenn ja, sollte man da hinterfragen warum!

Deine gewünschte XML Datei ist für MakeObj wohl das DAT. Zumindest wüsste ich nicht was man sonst in das XML schreiben würde als was heute in der DAT steht.

Kann durchaus sein ... ich kenn mich mit paks und deren erzeugung ned aus ! Dann müsst mich mal naeher damit befassen ...

Aber wenn in der dat alles drinnesteht, warum braeucht man dann nen grafisches tool um das makeobj zu befuellen ??? einfach die dat datei an das makeobj geben, und es kommt das fertige pak raus ....

Mal sehen, vielleicht schaff ichs mal mir das anzuschauen ....

Wenn Du das gerne programmieren möchtest, nur zu.

Was ich möchte und was ich kann, sind 2 verschiedene Dinge ^^
Wobei das hier wahrscheinlich eher nen Ressourcen Problem ist. Eigentlich will ich in meiner Freizeit spielen, und nur die PCs tauschen und die Arbeit zu Hause fortsetzen ^^

Ciao ...

[jonasbb]

Aber wenn in der dat alles drinnesteht, warum braeucht man dann nen grafisches tool um das makeobj zu befuellen ??? einfach die dat datei an das makeobj geben, und es kommt das fertige pak raus ....

in der dat stehen alle Informationen z.B. Geschwindigkeit, Lademenge, Kosten (bei Fahrzeugen).
Das grafische Tool wurde gewünscht, weil makeobj nur ein Kommandozeilenprogramm ist und es für Anwender (insbesondere Windows-Nutzer) ungewohnt ist mit der Kommandozeile zu arbeiten.

Das grafische Programm wäre dann halt gleich bei makeobj dabei (es gibt für Windows 2 Tools die das gleiche machen: siehe hier) und würde auch nicht mehr machen als man auch mit der Kommandozeile macht:
makeobj sagen wo die dat liegt, wie es gepakt werden soll und optional wie die pak heißen soll.

[Hajo]

Original von RHBaum
Aber wenn in der dat alles drinnesteht, warum braeucht man dann nen grafisches tool um das makeobj zu befuellen ??? einfach die dat datei an das makeobj geben, und es kommt das fertige pak raus ....

Im Moment ist das so. Man ruft MakeObj mit der Dat auf, die PNGs müssen passend im Filesystem liegen, und MakeObj generiert daraus ein PAK.

Viele Anwender tun sich jedoch mit der kommandozeile schwer, und viele möchten auch dei Syntax der DAT Dateien nicht lernen (z.B. die schreibweise der ganzen Parameter) und wünschen sich deshalb ein Werkzeug das einem die Arbeit abnimmt, eine DAT Datei (eigentlich sidn das nur Textdateien) zu editieren.

Original von RHBaum
Wobei das hier wahrscheinlich eher nen Ressourcen Problem ist.

Ja. Die Entwickler wollen lieber an anderen Dingen arbeiten, zumindest das Kernteam. MakeObj arbeitet wie ein Compiler, somit sind Programmierer damit glücklich, da es von der Arbeitweise dem Erstellen von programmen entspricht (Sourcecode -> Programm mit einem Compiler bzw. PNG+DAT -> PAK mit MakeObj)

[RHBaum]

Viele Anwender tun sich jedoch mit der kommandozeile schwer, und viele möchten auch dei Syntax der DAT Dateien nicht lernen (z.B. die schreibweise der ganzen Parameter) und wünschen sich deshalb ein Werkzeug das einem die Arbeit abnimmt, eine DAT Datei (eigentlich sidn das nur Textdateien) zu editieren.

Das waer dann aber eher ein Dat-Editor also wie eine Oberflaeche zu Makeobj.
Und klar, nu seh ich auch bissi das clientel ....
- ein vorhandene pak zu oeffnen
- die pngs und dats auszuspulen
- die ausgespulten dats zu bearbeiten (am besten mit nem fertigem Editor)
- die geaenderten dateien wieder zusammenzufassen zu nem neuen pak (vielleicht mit gleichen namen )

Klar, die Paketwickler haben das Problem ned, die haben die daten an den richtigen stellen und so vorliegen, aber die die Modifizieren wollen, die sind ja arm dran :-)

Klar, dann ist die Frage ob das wirklich gewollt ist ...
wenn sich leute durch nen einfacheres Handling dazu gemuesigt, selber mehr paks einzubringen, waers sicher ne tolle sache. Aber wenns nur dazu fuehrt, das mehr an den daten rumeditiert wird ...

Ciao ...

[jonasbb]

Original von RHBaum
Das waer dann aber eher ein Dat-Editor also wie eine Oberflaeche zu Makeobj.
Und klar, nu seh ich auch bissi das clientel ....
- ein vorhandene pak zu oeffnen
- die pngs und dats auszuspulen
- die ausgespulten dats zu bearbeiten (am besten mit nem fertigem Editor)
- die geaenderten dateien wieder zusammenzufassen zu nem neuen pak (vielleicht mit gleichen namen )

das ist eigentlich nicht erwünscht vorhandene paks zu bearbeiten
die paks waren dafür gedacht, das man nichts mehr machen kann (klar mit OpenSource ist das anders)
als Info: JimKnopf arbeitet an einem Programm was genau das kann paks zu manipulieren

Original von RHBaum
Klar, die Paketwickler haben das Problem ned, die haben die daten an den richtigen stellen und so vorliegen, aber die die Modifizieren wollen, die sind ja arm dran :-)

Welches pakset verwendest du?
pak64 ist OpenSource das kannst du dir auch modifizieren

[RHBaum]

das ist eigentlich nicht erwünscht vorhandene paks zu bearbeiten

Kann ich auch verstehen ...
Eigentlich haben die Pak Entwickler recht, das wenn sie sagen, bevor wer ein Pak fuer sich modifiziert, soll er doch lieber nen Bugreport einstellen (wenns wirklich wegen einem Fehler das beduerfniss aufgekommen ist).
Wenn er modifikationen will, die das verhalten grundlegend aendern, dann soll er sich das zeugs auch komplett selber zusammenbauen(können)

Welches pakset verwendest du?

Spielen tu ich mit pak128 (momentan)....
modifizieren tu ich momentan gar nix ^^ und ich glaub ich will es auch nicht :-)
Aber ich waer unmittelbar dran intressiert, das sich pak128.german weiterentwickelt ... von daher wuerde ich Tools begruessen, welche mehr leute begeistern koennen, und damit mehr ressourcen schaffen ...
Wenn denn die Tools nen "Hinderungs" oder "Abschreckungsgrund" sind !

als Info: JimKnopf arbeitet an einem Programm was genau das kann paks zu manipulieren

ja genau. Die Frage ist auch, ob man diese Energie da ned in ne richtung lenken sollt, wo das tool oder teile des codes universeller werden.
Zum beispiel das man (potentiellen) Pakentwicklern wirklich nen Grafisches tool in die hand drueckt, zum modifizieren der Dats .... denk mal das wuerde helfen.
Auf der anderen seite waere eine bib wo man lesend auf die daten in den paks zugreiffen kann, auch ned verkehrt. so das man reports und checks entwickeln kann, die die qualitat der pak-Daten verbessern.

Das waern nur so meine Ideen ....

Ciao ...