Ich versuche seit geraumer Zeit, eine Bahnhofs-GRF an meine Wünsche anzupassen.
Dazu gehört u. A. auch die mögliche Bauzeit!
Viele GRFs schränken ja die Bauzeit diverser Bahnhöfe ein, das mag berechtigte Gründe haben,
aber mich als "Modellbahner" und Gründungszeit-Fan schränkt es ganz schön ein

Ich habe jetzt eigentlich alle Dokumentationen zu Bahnhofs-GRF durch .... wo wird denn bitte das mögliche Baudatum festgelegt?

Vlt. kann ja dann auch mal der Anhalter Bahnhof gebaut werden:

   

Bernhard schrieb:Ich habe jetzt eigentlich alle Dokumentationen zu Bahnhofs-GRF durch .... wo wird denn bitte das mögliche Baudatum festgelegt?

Nirgendwo. Zumindest nicht in den "properties" wie du es von Fahrzeugen kennst. Stattdessen gibt es einen callback (13), der die Verfügbarkeit im Baumenü regelt.

s.a.

http://www.ttdpatch.de/grfspecs/m4nfoMan...tions.html und
http://www.ttdpatch.de/grfspecs/m4nfoMan...nsTut.html

für etwas bessere Erklärungen als in den nfo specs.

Gruß
Michael

Aha! Da muss man drauf kommen
Danke!
Ich lese mich umgehend ein!
Bei weiteren Fragen .... (danke für die schnelle Antwort!!!)

Hallo Michael,
Danke!!
Habe die passenden Stellen gefunden!


Was mich nach dem "Studium" der von dir verlinkten Seiten jetzt aber auch interessiert...
inwie weit unterscheiden sich die NFO-Programiersprachen m4nfo von Josef Drexler und nml
vom OTTD-Team?
Wahrscheinlich ist NML ja was ganz neues, konnte/durfte m4nfo nicht für OTTD weiterentwickelt werden?

Bernhard schrieb:Was mich nach dem "Studium" der von dir verlinkten Seiten jetzt aber auch interessiert...
inwie weit unterscheiden sich die NFO-Programiersprachen m4nfo von Josef Drexler und nml
vom OTTD-Team?
Wahrscheinlich ist NML ja was ganz neues, konnte/durfte m4nfo nicht für OTTD weiterentwickelt werden?

Beide Programme sind "Hochsprachen" die sich auf die nfo specs abstützen und das Erzeugen von grf-Dateien vereinfachen. Der Ansatz ist allerdings unterschiedlich, siehe hier:

http://www.ttdpatch.de/grfspecs/m4nfoMan...Intro.html

Gruß
Michael

(07.05.2014 09:52)mb schrieb:  Beide Programme sind "Hochsprachen frontends", sie stützen sich auf nfo ab und erzeugen eine grf-Datei. Der Ansatz ist allerdings unterschiedlich, siehe hier:

Die Aussage ist nicht korrekt. Im Gegensatz zu m4nfo, welches als Prä-Processor agiert und nfo-code erzeugt, welcher von grfcodec als eigentlicher compiler zu einem grf verarbeitet wird, ist nmlc ein eigenständiger Compiler, der eines solchen Umwegs über NFO nicht bedarf.

Sowohl nforenum/grfcodec (mit NFO als Programmiersprache) als auch nmlc (mit nml als Programmiersprache) sind eigenständige Implementierungen der grf specs (die mit nfo erstmal wenig zu tun haben - oder nur insoweit als NFO quasi als "NewGRF-Assembler" alle Dinge mit Ausnahme der Referenzen der "real sprites" und weniger Vergleichsoperatoren nur bei ihrem hexadezimalen Namen nennt, sprich, dass man größtenteils direkt die NewGRF specs programmiert, inklusive so lustiger Sachen wie die Notwendigkeit, Zahlen in big endian - Notation anzugeben etc.

planetmaker schrieb:

mb schrieb:Beide Programme sind "Hochsprachen frontends", sie stützen sich auf nfo ab und erzeugen eine grf-Datei. Der Ansatz ist allerdings unterschiedlich, siehe hier:

Die Aussage ist nicht korrekt. Im Gegensatz zu m4nfo, welches als Prä-Processor agiert und nfo-code erzeugt, welcher von grfcodec als eigentlicher compiler zu einem grf verarbeitet wird, ist nmlc ein eigenständiger Compiler, der eines solchen Umwegs über NFO nicht bedarf.

Doch, die Aussage ist korrekt. Ich kann sie aber gerne noch etwas präzisieren:

mb schrieb:Beide Programme sind "Hochsprachen frontends", sie stützen sich auf die nfo specs ab und erzeugen eine grf-Datei. Der Ansatz ist allerdings unterschiedlich, siehe hier:

Der "Umweg" über nfo-code (und die Nutzung von grfcodec als dessen compiler) ist hauptsächlich[*] effizienzbedingt. Ein "eigenständiger compiler", zudem in Python implementiert, macht in dieser Hinsicht keinen Sinn. Aus diesem Grund wird der von m4nfo erzeugte nfo code anschliessend von grfcodec zu einer grf-Datei kompiliert. Ich habe flüstern hören dass dies auch bei nmlc bei grösseren Programmen aus Effizienzgründen so gehandhabt wird.

[*] ein weiterer Vorteil ist die Möglichkeit einzeln kompilierte grf-Module zu vollständigen grf-Dateien zu "linken" (also der Verzicht auf die überflüssige Neuübersetzung nicht geänderten Programmcodes).

Gruß
Michael

Wiederholungen falscher Aussagen machen sie nicht korrekter. Du hast nur präzisiert, dass Du die Technik bzw. Begrifflichkeiten nicht verstanden hast und munter verschiedene Begrifflichkeiten vermischst. Das Möglichkeit von nmlc alternativ nicht nur grf sondern auch nfo auszugeben bedeutet nämlich nicht, dass nmlc nfo in irgendeiner Form verwendet und ein "Frontend" dafür sei oder nfo irgendwo intern verwendete.

Unabhängig davon irrelevant ist auch, dass es für den Endnutzer wenig Unterschied macht - außer dass ein Compiler das einzig notwendige Tool sein kann, ein Präprozessor jedoch immer zwingend die Verwendung eines Compilers im Anschluß erfordert.

planetmaker schrieb:Wiederholungen falscher Aussagen machen sie nicht korrekter. Du hast nur präzisiert, dass Du die Technik bzw. Begrifflichkeiten nicht verstanden hast. Das Möglichkeit von nmlc alternativ nicht nur grf sondern auch nfo auszugeben bedeutet nämlich nicht, dass nmlc nfo in irgendeiner Form verwendet und ein "Frontend" dafür sei.

Du hast erkennbar Leseprobleme. Und auch m4nfo "verwendet nfo" nicht "in irgendeiner Form" (es gibt es auch nur aus).

Gruß
Michael

(07.05.2014 11:18)mb schrieb:  Du hast erkennbar Leseprobleme. Und auch m4nfo "verwendet nfo" nicht "in irgendeiner Form" (es gibt es auch nur aus).

Genau diese Eigenschaft macht es (bzw. m4 mit den nämlichen Makros namens 'm4nfo') eben zu einem nfo-Präprozessor, nicht mehr, nicht weniger. Es verwandelt die m4-makros in nfo - die dann von grfcodec als Compiler zu dem binären Endprodukt verwurstet werden. Die Definition von Compiler ist eben die Fähigkeit Quellcode einzulesen und entsprechende für die Zielplattform verwendbare Binärdateien (hier grf) auszugeben.

planetmaker schrieb:Genau diese Eigenschaft macht es eben zu einem nfo-Präprozessor, nicht mehr, nicht weniger. Es verwandelt die m4-makros in nfo - die dann von grfcodec als Compiler zu dem binären Endprodukt verwurstet werden.

Sag ich doch (s.o.)

planetmaker (ergänzt) schrieb:Die Definition von Compiler ist eben die Fähigkeit Quellcode einzulesen und entsprechende für die Zielplattform verwendbare Binärdateien (hier grf) auszugeben.

"Verwendbar" aber im Sinne von i.a. "nicht lauffähig" (da zB Bibliotheksfunktionen oder externe Objektmodule durch einen Linker oder das BS noch hinzugefügt werden müssen).

Aber wenn dich das glücklich macht, schreibe ich gerne noch einmal explizit, dass der Gebrauch von m4nfo zur Erzeugung von grf-Dateien auch das Programm grfcodec zwingend benötigt. (m4nfo ist ein "Übersetzer" (Quellsprache -> Zielsprache), grfcodec ist ein "compiler" (~ -> bytecode)).


Was natürlich keine Einschränkung bedeutet, im Gegenteil. Denn diese "Kompilierung" von nfo und Grafik zu einer "ausführbaren" grf-Datei ist zwar trivial (nfo-code wird praktisch zu 100% in die grf-Datei übernommen, Grafik wird kodiert und komprimiert), aber durch die Grafik-Kodierung doch zeitaufwendig, was mit einem nativen Programm wie grfcodec viel schneller bewerkstelligt werden kann, als durch ein interpretiertes Programm (trotz Anwendung von caching etc).

Insofern ist das Gesamtsystem aus m4nfo-Modulen und grfcodec wesentlich schneller als die Verwendung eines "integrierten Programms", was dann auch noch interpretiert abläuft, und auf dass man möglicherweise auch noch schichtenweise zusätzliche Schichten draufpacken muss, weil man zB keine sinnvollen Makroprozessor-Eigenschaften von Haus aus hat. Von anderen Nachteilen mal ganz abgesehen.

Ich schrieb ja schon anfangs:

mb schrieb:Der Ansatz ist allerdings unterschiedlich

Gruß
Michael

Um 'mal zum Anfang zurückzukommen (denn es geht hier nicht darum, welches System irgendwo von irgendwem zu bevorzugen ist) sondern nur um faktische Korrekturen

(07.05.2014 09:52)mb schrieb:  Beide Programme sind "Hochsprachen frontends", sie stützen sich auf nfo ab und erzeugen eine grf-Datei. Der Ansatz ist allerdings unterschiedlich, siehe hier:

Ist und beibt einfach falsch, weil es Äpfel und Bananen vergleicht. Beides ist Obst und kann man Essen und macht satt, aber ist grundsätzlich verschieden. Auch wenn Du jetzt eine Diskussion daraus drehen willst, welche Obstsorte besser schmeckt (und uns erzählst, dass die Installation von m4, den ganzen Makros und grfcodec die 'bessere' Lösung für alle und überhaupt sei) um das letzte Wort und Recht zu behalten, geht das am Kern der Sache vorbei: Dass die hier zitierte Aussage falsch ist.

@Mods: Das ganze kann man jetzt ab inklusive Posting #5 splitten und mit dem Titel versehen "Unterschiede zwischen Präprozessor und Compiler"

planetmaker schrieb:[...]

Du willst darauf herumreiten dass "m4nfo" (es ist übrigens die "Sprache", nicht das Programm) nicht direkt eine grf-Datei erzeugt, sondern dass dies indirekt, über die Verwendung von grfcodec geschieht?

Ich habe das Gegenteil ja nicht behauptet, sondern lediglich in meiner (leider nur kurzen) Antwort an Bernahrd geschrieben dass die Ansätze verschieden sind, sich aber beide auf die nfo specs abstützen, und sich grf-Datei erzeugen lassen. Bzgl der Details hatte ich einen link angegeben.

Aber gut.

Ich habe meine Antwort an Bernhard überarbeitet:

mb schrieb:Beide Programme sind "Hochsprachen" die sich auf die nfo specs abstützen und das Erzeugen von grf-Dateien vereinfachen. Der Ansatz ist allerdings unterschiedlich, siehe hier: [...]

HTH
Michael

Oh je, so etwas wollte ich nicht lostreten...
Das es eine gravierenden Unterschied gibt, habe ich schon festgestellt:
NML-"basierende" GRFs lassen sich mit GRFCODEC nicht mehr "decodieren". (GRF2HTML streikt glaube ich auch)
Was einem bei m4nfo-basierenden aber auch nicht wirklich nutzt, weil sie m. M. n. so "unübersichtlich" sind, dass man kaum was findet!

Ich denke mal, die Frage welches "Tool" zu empfehlen ist, lasse ich lieber

(Trotzdem) Danke für die Infos!

(07.05.2014 13:59)mb schrieb:  Beide Programme sind "Hochsprachen" die sich auf die nfo specs abstützen und das Erzeugen von grf-Dateien vereinfachen. Der Ansatz ist allerdings unterschiedlich, siehe hier: [...]

Weil es sachlich falsch ist - und wir wollen den Leuten doch keinen Unfug beibringen?

Also nochmal langsam zum Verstehen der technischen Termini:
* Es gibt die grf-specs die beschreiben wie eine grf-Datei beschaffen zu sein hat.
* Es gibt die Sprache nfo (die sich sehr nahe an den grf-specs in ihrer hexadezimalen Herangehensweise orientiert). Ihr Compiler ist grfcodec
* Aus historischen Gründen sind die grf-specs und die nfo-Spezifika in der gleichen Wiki im gleichen Namensraum - das die Spezifikationen von grf-Dateien und deren Beschreibung in nfo nicht synonym (wozu denn sonst grfcodec überhaupt?).
* Es gibt die Sprache nml mit dem Compiler nmlc. Die Gemeinsamkeiten mit nfo beschränken sich auf die *gemeinsame* Grundlage beider Sprachen: die grf-specs.
* Der Compiler nmlc hat zwei Ausgabe-Modi, grf und aus historischen Gründen auch nfo - das ist aber nur eine kleine nachgeschaltete Ausgaberoutine.

* Für jede Sprache (nfo, nml, ...) kann man sich immer einen beliebigen Macro-Prozessor nehmen und dann lustig dazu passend Macro-Sammlungen programmieren, die das Schreiben des Codes in der jeweiligen Sprache hoffentlich vereinfachen. Den Output des entsprechenden Präprozessors füttert man dann den eigentlichen Compiler. Eine Art von Macro-Sammlung oder gar Code-Generator nutzt fast jeder, der ein NewGRF-Projekt gewisser Größe betreut.

Bernhard schrieb:NML-"basierende" GRFs lassen sich mit GRFCODEC nicht mehr "decodieren". (GRF2HTML streikt glaube ich auch)

Jede grf-Datei lässt sich mit grfcodec dekodieren. Sonst wäre es keine grf-Datei.

Bernhard schrieb:Was einem bei m4nfo-basierenden aber auch nicht wirklich nutzt, weil sie m. M. n. so "unübersichtlich" sind, dass man kaum was findet!

Wo ist irgendwas unübersichtlich? Was findest du nicht? Redest du vom Manual?

Gruß
Michael

Michael, ich gebe dir Beispiele, habe aber leider im Moment keine Zeit... reiche ich morgen Vormittag nach!

planetmaker schrieb:Weil es sachlich falsch ist - und wir wollen den Leuten doch keinen Unfug beibringen?

Natürlich nicht, daher werde ich für´s Publikum etwas weiter ausholen.

planetmaker schrieb:* Es gibt die grf-specs die beschreiben wie eine grf-Datei beschaffen zu sein hat.
* Es gibt die Sprache nfo (die sich sehr nahe an den grf-specs in ihrer hexadezimalen Herangehensweise orientiert). Ihr Compiler ist grfcodec

Da bringst du etwas durcheinander.

Zunächst ist richtig dass die "grf-specs" das Format einer grf-Datei beschreiben. Diese ist (in "Format 1") einfach eine lineare Anordnung sogenannter "sprites" (im neueren "Format 2" sind die im folgenden erwähnten zwei Arten von "sprites" voneinander getrennt).

Heute unterscheiden wir "real sprites", das sind in bestimmter Weise kodierte bzw komprimierte Spielgrafiken (wie in TTD), und - neu seit TTDPatch - "pseudo sprites". Diese kodieren keine Grafiken sondern sind Anweisungen und Daten die von TTDPatch und OTTD interpretiert und/oder an die jeweiligen internen Datenstrukturen zugewiesen werden, bzw mit ihnen verknüpft werden.

Diese Anweisungen und Daten stellen einen byte code dar, der durch die "Sprache" nfo beschrieben wird. Diese hat aber erst einmal gar nichts mit den "grf-specs" zu tun, die ja lediglich den Aufbau einer grf-Datei beschreiben. In der Tat gab es das grf-Format bereits vor der Entwicklung von nfo. Man konnte schon damals mit grfcodec die originalen TTD grf-Dateien dekodieren, die lediglich die Spielgrafiken (sowie einige Farbtabellen und Reliefs) enthielten. Und man konnte (geänderte) Grafiken wieder in eine grf-Datei kodieren.

Der später von TTDPatch eingeführte nfo code ("pseudo sprites") wird von grfcodec einfach in die grf-Datei eingefügt, dazu braucht es überhaupt keine "compiler"-Funktionalität.

planetmaker schrieb:* Es gibt die Sprache nml mit dem Compiler nmlc. Die Gemeinsamkeiten mit nfo beschränken sich auf die *gemeinsame* Grundlage beider Sprachen: die grf-specs.

Eben nicht, denn die grf-specs spezifizieren lediglich das Format einer grf-Datei, der "compiler" hingegen, was o.e. "pseudo-sprites" betrifft, übersetzt ganz einfach nml-Syntax in nfo. Ausserdem erledigt er (in nmlc) noch die Kodierung der Grafiken und schreibt beides zusammmen direkt in die zu erstellende grf-Datei, unter Beachtung des grf-Formats.

Weder die eine noch die andere der beiden zuletzt erwähnten Teilaufgaben rechtfertigen allerdings mMn die Bezeichnung "compiler" für das ausführende Programm. Und in Bezug auf die Umsetzung von "Hochsprache" zu nfo tun der nmlc "compiler" und m4nfo exakt dasselbe. Wie gesagt, in m4nfo ist lediglich die Grafik-Kodierung sowie die anschliessende Speicherung von nfo und kodierter Grafik in grfcodec ausgelagert. Wie gesagt, aus guten Effizienzgründen.

planetmaker schrieb:* Für jede Sprache (nfo, nml, ...) kann man sich immer einen beliebigen Macro-Prozessor nehmen und dann lustig dazu passend Macro-Sammlungen programmieren, die das Schreiben des Codes in der jeweiligen Sprache hoffentlich vereinfachen.

Ich weiss nicht worauf du hinauswillst, es gibt ja verschiedene Interpretationen des Begriffs "Makro", zB als feste (oder parametrisierte) Befehlsfolge in der SW-Entwicklung, oder als Zusammenfassung fester Benutzereingaben in Anwendungsprogrammen. m4nfo ist allerdings in M4 geschrieben, was eine Turing-vollständige Programmiersprache darstellt, nicht zu vergleichen mit "beliebigen Macro-Prozessoren" (wie zB CPP), deren Funktionsumfang nicht über reinen Textersatz hinausgeht (was dir möglicherweise nicht bekannt ist). Das bedeutet nun nicht, dass m4nfo M4 nicht für reinen Textersatz benutzt, das tut es sehr wohl, zB für "templating".

planetmaker schrieb:Den Output des entsprechenden Präprozessors füttert man dann den eigentlichen Compiler.

In der Tat, das ist allgemein bekannt und muss nicht extra erwähnt werden.

planetmaker schrieb:Eine Art von Macro-Sammlung oder gar Code-Generator nutzt fast jeder, der ein NewGRF-Projekt gewisser Größe betreut.

Mag sein. Aber auch hier will mir die Relevanz dieser Aussage im gegebenen Kontext nicht recht einleuchten.

Gruß
Michael

(07.05.2014 14:59)mb schrieb:  

Bernhard schrieb:NML-"basierende" GRFs lassen sich mit GRFCODEC nicht mehr "decodieren". (GRF2HTML streikt glaube ich auch)

Jede grf-Datei lässt sich mit grfcodec dekodieren. Sonst wäre es keine grf-Datei.

Bernhard schrieb:Was einem bei m4nfo-basierenden aber auch nicht wirklich nutzt, weil sie m. M. n. so "unübersichtlich" sind, dass man kaum was findet!

Wo ist irgendwas unübersichtlich? Was findest du nicht? Redest du vom Manual?

Gruß
Michael

ok, das mit dem decodieren nehme ich zurück, anscheinend war mein grfcodec zu alt, um NML-GRFs zu decodieren... wann immer ich es versuchte, es kamen nur leere Dateien heraus.
Mit der Aktuellen version (ich sag lieber nicht welche ich bis Vorgestern benutzt habe) geht es

Was die Unübersichtlichkeit angeht ...
"Früher" hat man schön der reihe nach programmiert. Leider scheint das Beispiel von Josef nicht mehr online zu sein.

...
Action 7
Acttion D
Action 8
Action 1
dann die Sprites
Action 2
...
Action 2 VAR
Action 6
Action 3
Action 0 (oft auch unmittelbar vor den Sprites)

...
...
...

"Heute kommen die alle irgendwie sortiert...
Z.B. alle Action0 direkt hintereinander usw ...
Wenn man also versucht, sich über das Lesen eines Codes in das Thema hineinzuarbeiten, ist dies heute wesentlich schwieriger als "früher".
Ob das nun an "Codegenerator" liegt, egal ob m4nfo oder NML .... weiß ich nicht.
Aber wahrscheinlich sollte ich sowieso endlich mal aufhören, fremden Code auszuspionieren.
Aber oft sind es Kleinigkeiten, die einen stören, die man beheben möchte, ohne auf das näöchste Update warten zu müssen.
Sei es ein Bahnhof der zu einer bestimmten Zeit nicht mehr baubar ist, oder eine Lok die sich nicht mehr im depot drehen lässe, oder einem Set fehlt ein bestimmter Anhänger....
Ganze Sets mache ich dann in ~ 15 Jahren, wenn ich in Rente gegangen bin!

Bernhard schrieb:Was die Unübersichtlichkeit angeht ...
"Früher" hat man schön der reihe nach programmiert.

Das tut man auch heute noch, bzw man kann es tun, muss aber nicht unbedingt. Trotzdem: daran hat sich nichts geändert.

Bernhard schrieb:Leider scheint das Beispiel von Josef nicht mehr online zu sein.

Jiosefs ttdpatch.net Seite ist immer noch online.

Bernhard schrieb:...
Action 7
Acttion D
Action 8
Action 1
dann die Sprites
Action 2
...
Action 2 VAR
Action 6
Action 3
Action 0 (oft auch unmittelbar vor den Sprites)

...
...
...

"Heute kommen die alle irgendwie sortiert...
Z.B. alle Action0 direkt hintereinander usw ...

Das kann man machen wie man will. Wichtig ist nur dass am Anfang die action8/action14 erscheint.

Man kann dann entweder jedes Fahrzeug für sich zusammenfassen, also action0, action1, action2, actionVar2, action3, action4, oder alle action0 für alle Fz, dann alle Fz-sprites in einem einzigen action1-Block (oder auch getrennt), wie man mag. Diesbzgl hat sich nichts geändert.

Bernhard schrieb:Wenn man also versucht, sich über das Lesen eines Codes in das Thema hineinzuarbeiten, ist dies heute wesentlich schwieriger als "früher".
Ob das nun an "Codegenerator" liegt, egal ob m4nfo oder NML .... weiß ich nicht.

Das liegt einfach daran, dass die einzelnen Autoren ihre grf-Dateien unterschiedlich aufbauen. Ich selber folge da auch keiner festen Regel, sondern ordne die "actions" so an, wie es für den Einzelfall (aus Gründen der Übersichtlichkeit) am besten ist.

[edit]

Bernhard schrieb:Ob das nun an "Codegenerator" liegt, egal ob m4nfo oder NML .... weiß ich nicht.

(Das habe ich vorhin überlesen)

Da ist natürlich etwas dran. m4nfo habe ich bewusst an der Struktur von nfo orientiert, einmal aus Kompatibilitätsgründen (man kann sogar reinen nfo-code in m4nfo einbinden, wenn man mag), aber vor allem aus Effizienzgründen habe ich an der manuellen Vergabe der Referenzen in der Kette der action2/VarAction2 festgehalten. Der andere "code-Generator" erzeugt diese Referenzen implizit, und benötigt auch für frei in den Switch-Blöcken plazierbare Fallunterscheidungen eine Unzahl von action0Ds mit denen er den erzeugten nfo-code anreichert. Das mag im Einzelfall nach einer Dekodierung der grf-Datei nur mit Mühe zu durchschauen sein.
[/edit]

Gruß
Michael