DonRazzi schrieb:... Straßensets, die Trams mitbringen (NA Roads) ... Brückensets, die keine passenden Straßen enthalten ...

Das hat einen guten Grund ... es gab (und es gibt sie immer noch) unzählige Kommentare, wie "Ich kann Strassenbahnlinien bauen, aber wo sind den die Fahrzeuge" oder "Wieso kann ich eigentlich keine Strassenbahnlinien bauen ? Die sind doch im Menu enthalten". Das ist der Grund, wieso NA Roads Strassenbahnen enthält. Diese sind auch abschaltbar, für Spieler die ihre eigenen Strassenbahnen mitbringen wollen. Einen separaten Tram-Set zu veröffentlichen wäre Unfug, den der eine Set wäre nutzlos ohne den Anderen. Die Anzahl von separaten Sets so klein wie möglich zu halten ist auch mein Ziel. Vielleicht gibt es einmal einen Mega-Kanada Set, wo alles drin ist. Wartet nur ab, bald werden wir auch Gelenkstrassenbahnen haben, und die auch in Mehrfach-Kombination verfügbar sein werden. Ob, diese in OpenTTD auch funktionieren weiss ich noch nicht aber in TTDPatch tun sie es. Diese Nordamerikanischen Grossstädte kommen ohne Strassenbahnzüge nicht aus.

Was die Brücken betrifft ... NA Bridges ist in Bearbeitung, es wird hauptsächlich modifizierte TBRS Brücken (mit Erlaubnis) enthalten, die mit NA Roads 'brick' und 'bitumen' Strassenoberflächen versehen werden.

Eddi schrieb:... Das sekundäre Problem ist, daß ohne "basecost"-Modifikation der Wertebereich für die Preise nicht ausreicht, das sollte meiner Meinung nach schleunigst behoben werden, sonst wird man niemals sinnvoll mehrere Sets nebeneinander benutzen können.

Ja, das hätte schon lange behoben werden können; es wurde ausreichend diskutiert ... Die modifizierten Basis-Kosten sollten sich nur auf den Set beziehen, in dem sie modifiziert wurden. Wenn keine veränderten Basis-Kosten enthalten sind, sollten die wirklichen Basis-Kosten verwendet werden. Übrigens, NA Roads verändert keine Basis-Kosten.

(13.03.2009 00:28)OzTransLtd schrieb:  Ja, das hätte schon lange behoben werden können; es wurde ausreichend diskutiert ... 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.

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

(13.03.2009 22:09)mb schrieb:  Der frühe Release von einfachen Sets, die im Extremfall lediglich eine Lok enthalten, ist mMn aber von Übel.

Klar, sehe ich auch so, da hilft es aber wenig, hier rumzumeckern, da sollte man eher direkt mit den GRF-Neulingen reden.

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

Muß ich dich darüber aufklären, daß der Plural von "Wagen" ohne "s" gebildet wird?

jein, es sind lediglich original-LKW verwendet worden, die mit passenden Umrüstmöglichkeiten versehen wurden.

Zitat: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.

Bist du schonmal über diesen Thread hier gestolpert?

Du kannst hier ja gerne lang und breit über deine Wünsche diskutieren, aber solange Peter an solchen Diskussionen nicht beteiligt ist, sehe ich die Implementierungschancen gegen 0 tendieren.

Zitat:für den DB Set ist das ziemlich vertrackt.

Fühl dich bitte ausdrücklich nicht unter Druck gesetzt

Zitat:[Geschichte der "basecosts"]

mir sind die Gründe der Einführung durchaus bewußt, deswegen hängt ein Umdenken bei der Verwendung der "basecosts" ja auch von der Erweiterung des Wertebereichs für die Kosten ab.

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

Ja, soll es auch nicht. Es geht um die "unabsichtliche" gegenseitige Beeinflussung von verschiedenen GRFs, weil beide die "basecosts" anders modifizieren, und deshalb die Preise nicht mehr wie beabsichtigt ausfallen.

Das liegt meiner Meinung nach ursächlich daran, daß die GRF-Autoren generell mit der Annahme herangehen, daß ihr Set das einzige sein wird, das geladen wird, und ihnen deshalb die Seiteneffekte der "basecosts" nicht bewußt werden.

Deswegen sollte man den Autoren beibringen, eine Änderung der "basecosts" nur dann vorzunehmen, wenn man sich ausdrücklich auf alle aktiven Sets beziehen will (z.b. Zwecks Schwierigkeitsgrad), und sich ansonsten nur die Einzelpreise zu verändern. Das ist die einzige Variante, wie man sicherstellen kann, daß auch im Spiel die Preise so ausfallen, wie vorgesehen, auch wenn andere Sets nebenher geladen werden. Ob diese Sets dann untereinander kompatible Preissysteme verwenden, steht hier überhaupt nicht zur Debatte.

Zitat:Gruß
Michael

Vielleicht solltest du das mal in deine Signatur packen

Eddi schrieb:... diese [private Basis-Kosten] 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.

Es ist mir bewusst das die Basis-Kosten global sind und es auch bleiben sollen; auch ist mir bekannt, dass diese dem Schwierigkeitsgrad und der Inflation angepasst werden. Aber, wo ein Wille ist ist auch ein Weg.

Wenn ein Set die Kosten modifizieren möchte, wird zuerst eine Kopie der globalen Basis-Kosten angelegt (das sind 49 Bytes). Diese Kopie(n) unterliegen den selben Regeln was Schwierigkeitsgrad und Inflation betrifft. Der Set modifiziert und verwendet dann seine 'privaten' Basis-Kosten.

Eine andere Variante wäre, das die Kost-Faktoren (0x17 für Züge) von maximal 255 auf 65535 erhöht würden.

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

Stimmt, aber wer als Spieler einfach alles was an Sets verfügbar ist benutzt ist selber schuld. Set Entwickler müssen miteinander reden. Der US-Set und Can-Set sind, was die Kostenstruktur betrifft, ziemlich kompatible und könnten gut miteinander in einem 'Engine Pool' Spiel verwendet werden; wenn nur dieser 'Engine Pool' besser implementiert worden wäre.

Eddi schrieb:... die GRF-Autoren generell mit der Annahme herangehen, daß ihr Set das einzige sein wird, das geladen wird, und ihnen deshalb die Seiteneffekte der "basecosts" nicht bewußt werden.

Das ist mir bewusst, darum wurden für die Strassenbahnen in NA Roads die Basis-Kosten nicht verändert, jedoch die Kosten-Faktoren herauf geschraubt. Dies hat nun, wie DonRazzi bemerkte, zu negativen Nebenerscheinungen geführt. Für komplette Bahnsets ist das kein Problem, auf jeden Fall solange wir nicht mit dem 'Engine Pool' konfrontiert werden.

Zitat: ... über diesen Thread [CB 1D] hier gestolpert? ... aber solange Peter an solchen Diskussionen nicht beteiligt ist, sehe ich die Implementierungschancen gegen 0 tendieren.

Wir haben genug über den 'Engine Pool' und seiner Implementierung gestänkert, nun warten wir geduldig auf eine Lösung. Es ist jedoch beinahe schon ein Jahr her und wir warten immer noch.

mb schrieb:... Der frühe Release von einfachen Sets, die im Extremfall lediglich eine Lok enthalten, ist mMn aber von Übel. ...

Das stimmt, aber wie sollen die Neulinge lernen NewGRF Sets zu entwickeln. Man muss klein anfangen. Es ging mir auch mal so mit dem Norwegischen Bahnset, den ich heute als schlecht und wirklich überholungsbedürftig betrachte.

Eddi schrieb:... man muß auch nicht ein Set als ein GRF veröffentlichen, sondern das ganze auch modularer gestalten, wie zum Beispiel Georges ECS. ...

Das ist wirklich ein schlechtes Beispiel. ECS sollte EIN Set sein; z. B. lässt ein Spieler den Agri-Vektor weg, kommen plötzlich wieder 'Grain/Wheat/Maize' anstatt 'Cereals' zum Zuge. Wir als Fahrzeug Set Entwickler müssen da mitspielen. Ich hoffe nur die FIRS-Leute machen es besser.

(15.03.2009 00:01)OzTransLtd schrieb:  lässt ein Spieler den Agri-Vektor weg, kommen plötzlich wieder 'Grain/Wheat/Maize' anstatt 'Cereals' zum Zuge. Wir als Fahrzeug Set Entwickler müssen da mitspielen. Ich hoffe nur die FIRS-Leute machen es besser.

Das ist aber ein Problem der Implementierung selbst, nicht der Modularisierung. Wenn ich den Agriculture-Vector abschalte, dann sollen gefälligst gar keine Agrar-Industrien auftauchen, Also insbesondere auch nicht die originalen Industrien.

[Basiskosten]
Es ist ja schon komisch, der Engine pool wurde ziemlich schnell experimentell akzeptiert, die Basis kosten einfach zu privatisieren lehnt man aber strickte ab. Man könnte z.b. mit der Properity Override eine Ausnahme für die zwei mir bekannten GRFs (bridge und build von Pikka, meins zähle ich mal nicht dazu) machen. (GRFID 0 oder -1 wäre z.B. global)
(Pikka würde sicher auch nicht weinen, wenn sein GRF obsolete werde würde, wenn man es mit seiner anderen GRFs vergleicht, ist es ja ein Klacks.)

Alle anderen Sets missbrauchen hauptsächlich die Basiskosten um für ihr Set bessere Kostenbandbreiten zu haben.

Wen man jedoch länger über die ganze Kostensache nachdenkt, muss man sich eingestehen, dass das bei (O)TTD ziemlich schnell nebensächlich ist.

Viel eher kommt es auf die Kombinierbarkeit von den Sets an, also z.B. die transparente Lock an ICE waggons anzukoppeln etc. (oder mit einer ICE Lock Kohle durch die Lande führen

Dieses Problem kann man aber meines Erachtens dem Spieler überlassen. Er sollte doch auch noch etwas dazu beitragen können.

Edit: ein interessanter Aspekt wäre jedoch im MP Bereich, wo z.B. verschiedene Firmen verschiedene Sets einsetzen können, da müsste man dann aber eben die (privaten) Basiskosten abgleichen können.

[ECS]
ich verstehe jetzt nicht ganz weshalb das ECS Set als ein einzelnes GRF einfacher wäre für die Fahrzeugsets. Oder möchtest du dass man entweder keine ECS vektoren oder alle gleichzeitig hat?
Sonst kann man doch einfach gucken, ist Agri geladen, sind es die neuen Cargos, ist Basis geladen, sind es die defautl, ist nur town geladen sind es keine.
Wäre doch viel komplizierter, wenn du da auf die Parameter oder was auch immer gucken müsstest.
ECS ist fast eine eigene "Wissenschaft", denke nicht das FIRS auch so weit gehen wird...

Grüsse
Ammler