Simu-Editor

[sojo]

Zuerstmal möchte ich Hajo bei dem was er oben schrieb vollkommen zustimmen.

Original von FrankP
Die Grafiksetverwalter würden sich glücklich schätzen, wenn sie mehr Grafiken angeboten bekommen würden.
Mir persönlich gefällt es nämlich nicht so wirklich, das seit einiger Zeit sehr viel auf das 96er Comic gezogen wird. Kaum hat jemand eine Grafik für 64er oder 128er veröffentlich wird sofort gedrängt, mach doch auch was für Comic.

Es mag eine Lücke in der Grafikgestaltung gegeben haben. Aber zur Zeit wird eine so starke Fokusierung auf Comic gefahren, das die anderen Sets schlicht ins Abseits gestellt sind.

Stimmt. Anfangs habe ich versucht einige Grafiker auf das pak96.comic aufmerksam zu machen, da ich kaum Grafiken hatte. Dies wird aber von mir schon lange nicht mehr gemacht, da oft sehr viele Grafiken angeboten werden.

Wenn jemand fragt, dann sind es die Spieler, denen ist pak96.comic wohl noch zu unausgereift und deshalb brauchen sie noch Grafiken.

Original von FrankP
Der Punkt für mich ist, das solche Verlangen immer mit Schwächen in den Grafiksets begründet werden. Aber aktive Mitarbeit an den Grafiksets nicht stattfindet.

Wer sich in den Foren so umschaut wird nämlich feststellen, das es seit Jahren kaum Feedback über die Grafiksets gibt. Und deshalb stehen die Grafiksetverwalter eigentlich im nichts. Sie wissen schlicht nicht, wo die Probleme liegen.

Ich befürchte das Problem liegt wo anderst. Die Spieler erkennen durch die Fülle von Fahrzeugen, Gebäuden, etc. den Faden oder das Problem garnicht. Sie merken das etwas nicht stimmt. Aber sicher oft nicht was.

Ich glaube nicht das der Simu-Editor später dazu benutzt wird für das er gemacht wird. Ich denke die Spieler werden sich die paks eher kaputt cheaten, es sei denn es wird eine "zurücksetzen" Funktion eingebaut.

Ich glaube viel hilfreicher wäre ein Werkzeug, welches die Paks einliest, analysiert und auswertet.

Mal angenommen es geht um die Loks. Dann wäre es wünschenswert das eine Grafik anzeigen würde von wann bis wann eine Lok verfügbar ist und wann nicht. Eine weitere Grafik könnte zeigen welche Leistungen in welchen Jahren zur Verfügung stehen, usw usw.

Mit solch einem Tool könnten die Spieler sich dem Problem nähern und es dem Pakset-Maintainer mitteilen.

[Wurzelgnom]

Eins sollte Jim Knopf allerdings bedenken.

Wer ein Tool erstellt und verbreitet, dessen einziger Zweck des Ändern geschützter Daten ist, begibt sich rechtlich in Deutschland auf sehr dünnes Eis.

Wie das Ändern von Daten in einer Binär-Datei vor einem Gericht bewertet wird ist dabei nicht ganz sicher.


Und für die Verbreitung kann auch der Forums-/Serverbetreiber zur Verantwortung gezogen werden.

[prissi]

Ich denke, dass mit OpenSource ein solches Tool sicher nur ein Frage der Zeit ist. Mit der nächscten Pak-Revision geht das dann aber nicht mehr, was immer mal wieder vorkommt. daher sollte das Tool cshon sauber offsets etc. überprüfen. Sonst machen sich Ahnunglose ihre Files kaputt und ich bin schuld ...

Falls übrigens etwas aus dem Simutrans-Quellcode bentuzt wird, muss auch das Tool im Quellkode vorliegen.

[Hans Dampf]

1. Zum Lesen von Daten würde ich dieses Tool benutzen. Dann bekomme ich die Daten schneller in meine sebstgestrickten Calculator Tabelle.

2. Beim Verändern der Daten z.B. Leistungen oder Preise stört man wahrscheinlich eine mühsam aufgebaute Balance. Mich hat aber auch schon gestört, das gerade bei Pak 64 vor 1900 es eine Olindustrie, aber keinen Transportanhänger gibt. "Adler" als Mehrfachtraktion.... Da wäre ich auch einer, der schnell mal eben das Tool benutzt, statt Bugreport zu schreiben.

Gruß
Hans Dampf

[Wurzelgnom]

Original von Hans Dampf
.... "Adler" als Mehrfachtraktion.... Da wäre ich auch einer, der schnell mal eben das Tool benutzt, statt Bugreport zu schreiben.
...

Was aber mit diesem Editor nicht gehen wird. Denn hier sollen ja nur vorhandene Einträge geändert werden.

Nicht vorhandene Einträge kann man binär aber nicht hinzufügen.

Die Binär-Datei muss exakt ihren Aufbau/Länge behalten, sonst ist sie einfach kaputt.

Und sollte dieser Editor kommen, sind alle Spielstände mit geänderten pak-Dateien als Unikat anzusehen. Das bedeutet, das immer alle geänderten pak-Dateien mit dem Spielstand zur Verfügung gestellt werden müssen.

Und ich glaube, keiner hat Lust sich x Versionen von Grafiksets auf den Rechner zu machen, nur um solche Spiele mal anzusehen oder zu testen.

Damit dürfte kaum einer einen Finger krümmen, wenn es bei solchen Spielen zu Problemen kommt.
_____________________________________

Was die Daten angeht, fehlt schlicht eine Dokumentation zu den Grafiksets.

Kann aber Jeder im Wiki drann mitschreiben.
_____________________________________

Original von Alexander Browse
...
vilvohs Arbeiten (Int. Forum, in der Regel pak64) werden kaum beachtet. Dabei ist er eine echte Grafikfabrik. gauthier kreiert fließig 128er Werke. Im tschechischen Bereich passiert auch so Manches.
Ganz zu schweigen vom britischen pak128-Ableger.
...

Die Grafiken der beiden und anderer werden schon zur Kenntnis genommen. Der größte Grafikmangel besteht vor 1930 respektive fürs 19. Jh. Und dafür ist recht wenig dabei.

Die Gebäude von gauthier sind eher was fürs 21. Jh statt fürs 19. Jh.

[Hajo]

Original von FrankP
Was aber mit diesem Editor nicht gehen wird. Denn hier sollen ja nur vorhandene Einträge geändert werden.

Nicht vorhandene Einträge kann man binär aber nicht hinzufügen.

Die Binär-Datei muss exakt ihren Aufbau/Länge behalten, sonst ist sie einfach kaputt.

Und sollte dieser Editor kommen, sind alle Spielstände mit geänderten pak-Dateien als Unikat anzusehen. Das bedeutet, das immer alle geänderten pak-Dateien mit dem Spielstand zur Verfügung gestellt werden müssen.

Das müssen sie auch wenn man mit MakeObj modifizierte Varianten aus den Original-Quellen erstellt hat. Ist also nicht schlimmer als der bisherige Zustand.

PAK Files sind intern Baumstrukturen. Man kann neue Knoten einfügen ohne die Datei zu zerstören. (Edit: man muss dann allerdings auch den Vater-Knoten und den Datei-Deskriptor anpassen - es kann aus den Simutrans Quellen entnommen werden wie diese aufgebaut sind). Allerdings ist das mit einem Hex-Editor von Hand sehr knifflig, mit so einem Tool wie SimuEdit aber nicht unmöglich. Das hängt ganz von Jim's Ehrgeiz ab, wie weit er den Editor treiben möchte.

[Jim Knopf]

Da habt ihr aber fleißig diskutiert. Das freut mich. Zuerst also einmal danke an alle Diskutanten.

Die Meinungslage ist ja ziemlich weit gestreut. Wahrscheinlich werde ich noch weitere Fortschritte und Richtungsentscheidungen hier posten, bevor ich entscheide, ob ich tatsächlich das Projekt veröffentlichen werde. Hinweise und Anregungen sowie auch Kritiken sind daher weiter willkommen.


@Grafik:
Bezüglich der aktuellen Grafiksituation bin ich immer noch der Meinung, dass das Problem teilweise hausgemacht ist. Gerade die Verkapselung führt dazu, dass die Grafiker unter sich bleiben. Ich habe vor einiger Zeit selber mal an einem Bahnsteig gebastelt. Es war äußerst schwierig, Kopiervorlagen zu bekommen. Grafiken in pak-Dateien sind nun mal unbrauchbar dafür.

Im Civilization-Umfeld, in dem ich einige Jahre aktiv war, gab es wahre Meister der Grafik. Die zweite Reihe hat dann von den vorliegenden GrafikenTeile rausgeschnipselt, neu kombiniert und überraschende Ergebnisse erzielt. Einige haben Grafiksets aus ganz anderen Spielen portiert. Natürlich jeweils nur mit Erlaubnis des Urhebers, falls es sich um keine freie Ware handelte. Im Endeffekt kursieren heutzutage zehntausende Grafiken, seien es nun Einheiten, Terrains oder Gebäude. Aus diesen Grafiken lassen sich wieder ganz neue Spielideen fabrizieren.

Das Ändern von Grafiken sieht mein Programm wohlweißlich nicht vor. Aber das Thema ist hier aufgekommen. Meines Erachtens wäre eine Abkehr von der pak-Systematik für das Gesamtprojekt Simutrans sicher hilfreich. Eventuell sollte man dafür einen eigenen Thread aufmachen.


@Namensgebung:
Ich denke, dass dies das allerkleinste Problem darstellt. Ein Name, der der Sache gerecht wird, ohne das Falsche vorzugaukeln, ist sicher schnell gefunden. Vielleicht habt ihr ja schon Ideen.


@Windows:
Nun, zuallererst war und ist es mein persönliches Projekt. Ich nehme dies u.a. auch, um mich mit den MFC vertraut zu machen. Dazu habe ich in der Vergangenheit schon zwei oder drei Anläufe genommen. Der jetzige scheint endlich erfolgreich zu sein. Auch darum macht mir das Projekt momentan so viel Spaß. Dass ich damit nicht allen gerecht werde, ist mir klar. Wenn ich mir die Simutrans-Download-Zahlen anschaue, scheint aber immerhin zweidrittel aller Spieler auf Windoof aufzusetzen.


@Probleme durch Programmgebrauch /-mißbrauch:
Das Thema macht mir selber Bauchschmerzen. Zur Zeit ist es nur ein Viewer. Es werden die Daten der paks angezeigt. Schlüsse daraus können momentan nur vom Betrachter gezogen werden. Man müsste sich also die Liste der vehicles ansehen um zu kontrollieren, ob z.B. Zeitbereiche nicht abgedeckt sind oder einzelne Güter nicht transportiert werden können. Automatische Checks einzubauen wäre eine reizvolle Herausforderung.

Das Thema des Mißbrauchs wird dann aktuell, wenn aus dem Viewer ein Editor wird. Einerseits ist natürlich das Format der binären Datei heilig. Alle Offsets der einzelnen Daten sind mir bekannt. Ein Zurückschreiben von Daten auf die alte Stelle also möglich. Das heißt, dass aus einem Startjahr 1880 mit vergleichsweise einfachen und unkritischen Mitteln ein Jahr 1830 gemacht werden kann. Die Qualität zu testen, das ist denke ich auch leicht organisierbar.

Was dabei gar nicht geht ist, dass Originaldateien überschrieben werden. Meine Änderungen werde ich logischerweise in ein anderes Verzeichnis schreiben, schon aus eigener Sicherheit. Damit hat es dann jeder in der Hand, ob er mit der Änderung oder lieber doch mit dem Original spielt.

Größere Herausforderungen stellen sich erst dann, wenn zusätzliche Daten erzeugt werden sollen (z.B. Doppeltraktion) oder umgekehrt Daten gelöscht werden sollen. Spätestens da stellt sich die Frage: schreibt man in dem Fall nicht lieber gleich eine komplett neue Datei? In neuester Version? Nicht zu unrecht habe ich diesen Punkt ziemlich nach hinten geschoben. Weil ab da hat man einen erheblichen größeren Testbedarf. Und eine erheblich größere Verantwortung. Da gebe ich allen Mahnern recht. Wenn man so etwas macht, muss es schon Hand und Fuß haben, sonst hat man den Teufel mit dem Beelzebub ausgetrieben. Dafür werde ich sicher eure tätige Mithilfe erbeten - Stichwort Betatester.


@Quellcode:
Bisher habe ich vollständig eigenen Code geschrieben. Wie gesagt möchte ich mein Programmierwissen mit dem Projekt erweitern. Einfaches Abtippen oder copy/paste helfen da nicht wirklich. Ausnahme ist das total simple Makro zur Umwandlung des Objekttyps (VHCL usw.) in einen long. Das musste ich einfach übernehmen. Der andere Grund für die Eigenprogrammierung ist, dass sich mir einige kompliziert anmutenden Konstrukte nicht direkt erschließen. Mittlerweile bin ich in meiner Erkenntnis weiter, aber anfangs waren mir nicht alle Programmstellen klar. Dann lieber auf eigene Faust probieren und sehen was raus kommt. Und siehe da, nach einiger Zeit wurden mir die Feinheiten klarer. Vor allem die Bit-Klauberen und vereinfachten Rechenprozeduren durch einfaches Bitverschieben waren am Anfang nicht wirklich eingängig. Sie helfen aber sicher dabei, die Performance des Spiels hochzuhalten.

Falls es zur Veröffentlichung des Projekts kommt, wird selbstredend der Quellcode mit veröffentlicht. Ich setze dann voraus, sich keiner über meinen Programmierstil mokieren wird. Schließlich weiß ich, wo ein "goto" in Simutrans versteckt ist.


@Versionen:
Genauso wie die offsets liegen die Versionen der einzelnen Datenstrukturen offen. Aktuell verarbeite ich keine Versionsstände, mit denen ich nix anfangen. Ich vergleiche sie auch noch zusätzlich mit hinterlegten Satzlängen, obwohl ich nicht sicher bin, ob das notwendig ist. Da ich auf dem Code der 99.17 aufgesetzt habe, verarbeite ich momentan keine Brücken der 102er-Version. Dort hat sich also was an der Satzstruktur geändert. In einem solchen Fall hat der Anwender Pech. Die Daten sieht er nicht, da mir der Satzaufbau unbekannt ist.


@International:
Nachdem hier schon die internationale Gemeinschaft angesprochen wurde. Als neuen Punkt werde ich mal prophylaktisch aufnehmen, künftig englische Variablennamen usw. zu benützen. Kann nie schaden.



Ich hoffe, ich habe keinen Beitrag übergangen. Wenn dem so wäre, sagt einfach Bescheid. Und nun weiter mit der Diskussion oder spielt Simutrans.


PS: sorry für den vielen Text

[Wurzelgnom]

Original von Jim Knopf
...
@Grafik:
Bezüglich der aktuellen Grafiksituation bin ich immer noch der Meinung, dass das Problem teilweise hausgemacht ist. Gerade die Verkapselung führt dazu, dass die Grafiker unter sich bleiben. Ich habe vor einiger Zeit selber mal an einem Bahnsteig gebastelt. Es war äußerst schwierig, Kopiervorlagen zu bekommen. Grafiken in pak-Dateien sind nun mal unbrauchbar dafür.
...

Ich weis ja nicht, wann 'vor einiger Zeit' war.

Inzwischen ist das pak64 komplett in einem öffentlichen SVN.
Das pak128.britain ebenfalls.
Und auf graphics.simutrans.com steht auch einiges an Grafiken zur Verfügung.
____________________________________

Da es um Herausforderungen geht.

Wie wärs mit einem neu programmierten Makeobj mit grafischer Oberfläche, das auch mehrere Simutransversionen beherrscht?

Denn für viele Windows-Nutzer ( weltweit ) ist der Umgang mit der Komandozeile ein großes Problem. Vermutlich ist das der abschreckendste Punkt für viele.

[Hans Dampf]

Original von FrankP
..............
Denn für viele Windows-Nutzer ( weltweit ) ist der Umgang mit der Komandozeile ein großes Problem. Vermutlich ist das der abschreckendste Punkt für viele.

Kommandozeilen sind ein Problem? Aber ein einfach zu lösendes. Gibt genug andere Problem, wo man sich mit Kommandozeilen nicht rumschlagen muß.......

Ich bin selber als User mit Atari-TOS angefangen. Dann mußte ich mich gerade noch mit DOS rumschlagen. Ein Greuel dabei war schon die geforderte Präzision. Beim Atari mußte man ungefähr den Dateinamen wissen. Und hat den dann in der Auswahl angeklickt. Und schon war die Datei geöffnet. Und bei DOS? Wie waren noch gleich die Schalter für dir? Und dann sah man den Dateinamen. Und mußte den fehlerfrei eintippen.........
Da habe ich manchesmal gemault. DOS ist ein Mist........

Das es auch unter Windows Schalter ähh Hotkeys gibt, dazu folgendes. Nachdem die Sekräterinnen die ****** Strg-Sequenzen auswendig gelernt hatten, hatten die damit schneller eine Datei geöffnet, als die Maus gefunden..... Und somit wurden die schon in Atari-Windows-Programme wieder eingeführt.

Andere sagen: Wenndoofs, dann Mouse.
Und meinen, wenn das Programm sich nicht zu 100% mit der Maus bedienen läßt, wird es mit der Akzeptanz schwierig.......
Bei windows merkt sich keiner, Schalter und deren Abk. Wozu? der Schalter-Text steht doch da. Und nun wird ein Häkchen davor gesetzt. Oder eben nicht. Eleganter finde ich den eingerahmten Text, welche normalerweise außerhalb oben und rechts durch grau angedeutet "Schatten wirft", als würde dieser Schalter hervorstehen. Und im "gedrückten " Zustand ist der "Schatten" unten und links innerhalb des Rahmens. Die Lösung in diesem Editor unten mit dünnen und dicken Rahmen gibt dann Probleme, wenn ich den "Radiobutton", als den einzigen Button, der über die "Enter" Taste erreichbar ist, kenntlich machen will. Der ist normalerweise dick, ersatzweise doppelt gerahmt.

[Jim Knopf]

Ich habe weitergewerkelt. Entstanden ist eine Version, die auf allen Windows-Versionen (ab Win95) lauffähig sein sollte. Es handelt sich um einen reinen Viewer. Es werden also keine pak-Dateien verändert. Nichtsdestotrotz kann die Version insbesondere den pak-Entwicklern helfen, sowohl korrupte pak-Dateien zu finden als auch logische Ungereimtheiten innerhalb der Zusammenstellungen zu finden. So kann die Frage "gibt es ein Fahrzeug für Wolle für die Zeit vor 1956" leicht beantwortet werden.

Beim allerersten Start kommt eine Meldung, dass keine "alte Sitzung" gefunden wurde. Danach klickt ihr auf Datei->Öffnen und wählt ein beliebiges Verzeichnis aus. Dieses Verzeichnis und alle seine Unterverzeichnisse werden dann nach pak-Dateien durchsucht und diese anschließend in Listenform dargestellt.

Wie weiter oben bereits geschrieben ist der aktuelle Stand noch weit davon entfernt, alle Attribute sauber darzustellen. So gebe ich bspw. momentan nur an, wie viele verschiedene Trailer an eine Lok angehangen werden können, aber nicht welche. Es bleibt also noch etwas zu tun. Trotzdem würde mich eure Meinung zum aktuellen Stand interessieren.

Achja, momentan lassen sich nur Spalten mit Zahlenwerten sortieren, nicht aber Spalten mit Texteinträgen.


PS: Ich habe das Programm nun "JimsViewer" genannt.