Eddi schrieb:Es gibt in der Open Source Welt den weit verbreiteten Grundsatz "release early, release often", und du hast selber erst letztens gesagt, daß Georges "unfertige" ECS-Implementierung im Großen und Ganzen von Vorteil gewesen ist. Wichtig ist an der stelle vor allem, die Dinge auch als "unfertig" zu deklarieren (z.B. indem man "alpha" und "beta" dranschreibt)

Ja. ME kommt es dabei aber vor allem auf die Intention an. "Grosse" Sets erfordern nun einmal nicht nur einen grossen Arbeitsaufwand, der naturgemäss ihre Fertigstellung verzögert, sondern sie enthalten zumeist auch Abhängigkeiten, entweder innerhalb des Sets selber oder als externe Abhängigkeiten, zu anderen aber zugehörigen Sets wie zB George´s ECS Implementierung. Hier ist es oft schwierig Vorabversionen zu veröffentlichen bevor die vorhandenen Abhängigkeiten einigermassen abgedeckt sind.

Der frühe Release von einfachen Sets, die im Extremfall lediglich eine Lok enthalten, ist mMn aber von Übel. Ich kann verstehen dass jemand der sich erstmalig mit der Erstellung von newgrfs beschäftigt seine frühen Erfolge irgendwie mitteilen möchte, aber er soll nicht gleich völlig unfertige und in hohem Masse verbesserungsbedürftige .grfs auf den Markt werfen. Das Internet "vergisst" nämlich nicht, und die Entwicklergemeinde leidet auch heute noch unter .grfs die vor vielen Jahren erstmalig freigesetzt wurden, mittlerweile aber eher als "Schadsoftware" eingestuft werden müssen.

Eddi schrieb:[german RV set]

Das würde ich allerdings ausdrücklich in meine Interpretation von "unfertig" einschließen, denn die LKW sind ja bekanntlich schnell danebengehackt worden. Ich will dieses Vorgehen hier ausdrücklich gutheißen, aber es wäre halt schöner, wenn ich die LKW stattdessen aus einem anderen Set nehmen könnte

Gibt es denn überhaupt schon LKWs? In v0.11b noch nicht.

Eddi schrieb:es ist mMn durchaus legitim, mit einem großen Set wie dem DBSet zu starten, und dann ein paar kleinere Erweiterungssets hinzuzufügen. Spontan fiele mir da eine unsichtbare Lokomotive für Abstellgleise ein, oder auch ein Rangierlokomotivenset, die ja im DBSet gar nicht enthalten sind. Oder man nimmt noch ein Schweizer und ein italienisches Set hinzu, und bildet dann grenzübergreifenden Verkehr über die Alpen ab, indem man die Karte in Regionen aufteilt

Das sind akzeptable Gesichtspunkte die ich selber schon einige Male erwähnt habe. Nur ist mMn das "multipool feature" von OTTD dafür ungeeignet. Ich bin nicht der einzige Entwickler der gerne ein vernünftiges Interface für die gleichzeitige Verwendung von Fz-.grfs verwenden würde. Aber diese Wünsche wurden bis heute komplett ignoriert.

Eddi schrieb:Nebenbei, man muß auch nicht ein Set als ein GRF veröffentlichen, sondern das ganze auch modularer gestalten, wie zum Beispiel Georges ECS. Oder man könnte das DBSet in Epochen aufteilen, aber davon erzähle ich auch nicht zum ersten mal.

Jaja. Ich habe darauf auch schon mehrfach geantwortet. Bevor man aber mit der Programmierung beginnt muss man ein fertiges Konzept haben. Für die ECS-Vektoren war das relativ einfach, für den DB Set ist das ziemlich vertrackt.

Eddi schrieb:

OzTransLtd schrieb:Die modifizierten Basis-Kosten sollten sich nur auf den Set beziehen, in dem sie modifiziert wurden.

Nein, diese Variante wurde von den Devs ausdrücklich abgelehnt, denn "basecosts" sind in den Spezifikationen ausdrücklich als global definiert. Das zu ändern steht außer Frage, denn einige NewGRFs vertrauen darauf, daß diese Variablen global sind, denn die "basecosts" können dadurch wie ein Schwierigkeitsgrad behandelt werden.

WIMRE hat dies damals Josef eingeführt und zwar wegen des DB Set, dessen "historische Preise" durch den vorhandenen Wertebereich nicht abgedeckt werden konnten. Der US-Set, der höhere Wartungskosten benötigte, hatte diese durch Verwendung einer fremden Kostentabelle (Schiffe?) bereitgestellt, aber für die Kaufpreise war das nicht möglich.

Man hätte damals aber auch diese fahrzeugbezogenen Kosten als "privat" implementieren und lediglich die Infrastrukturkosten als globale Variablen belassen können. Viel geholfen hätte das aber auch nicht, denn mittlerweile gibt es ja auch Sets die allgemeine Infrastrukturkosten verändern.

Und selbst wenn es private Kostenvariablen gäbe wäre dies keine Lösung für die gleichzeitige Verwendung kostenmässig inkompatibler Fahrzeugsets.

Gruß
Michael