Hallo!

Ich bin neu in diesem Forum und möchte daher allen mein Dankeschön ausdrücken, die an der Fortentwicklung meines alten Lieblingsspiels aus Jungendtagen arbeiten, besonders an der Entwicklung neuer Fahrzeugsets (wobei auch ich zu denjenigen gehöre, die sehnsüchtig auf das DBSetXL 0.9 warten...).

Zwar bin ich kein Programmierer, habe aber mit Hilfe meines Bruders ein eigenes "Add-On" zum DB-Set erstellt, das bereits um 1900 anfängt. Es handelt sich dabei um eine Überarbeitung des angelsächsisch geprägten "Early-Vehicles"-Set aus dem GRF-Crawler (olds.grf): Es umfasst einen Omnibus (dessen Grafiken ich nur leicht überarbeitet habe), zwei neue Dampfloks (pr. T2 und T3 in grün) und je einen Personenwagen (grün) und Gepäckwagen (braun). Es handelt sich also um Fahrzeugtypen, wie sie um 1900 im preußischen Teil des damaligen Deutschlands unterwegs waren, s. Bild:



Mittels Grfcodec habe ich die Grafik-Sprites überarbeitet und die nfo-Datei derart angepasst, dass die Fahrzeuge richtig auf dem Gleis sitzen und einen einigermaßen angemessenen Kuppelabstand zueinander haben (was bei vielen anderen Sets leider häufig nicht der Fall ist). Die "Drecksarbeit" ist also schon getan.

Das einzige, was ich noch ändern will, sind einige wenige betriebliche Parameter:

1) Die pr. T2 (und mit ihr die beiden Waggons) soll erst ca. 1880 erscheinen und nicht bereits 1825, wie die "Rocket", die sie grafisch ersetzt.
2) Der Personenwagen sollte in der Lage sein, neben Passagieren alternativ auch Touristen zu befördern.
3) Der Gepäckwagen sollte in der Lage sein, alle ECS-typischen Frachtarten außer Passagiere und Touristen zu transportieren, insbesondere Post.

Leider komme ich beim Ändern in der nfo-Datei nicht weiter. Vielleicht kann mir jemand helfen, das Set fertigzustellen? Sofern sich keine urheberrechtlichen Widerstände äußern, würde ich das Set anschließend zu Download bereitstellen. Vielen Dank für Hilfe im Voraus, mit freundlichen Grüßen,

verdennis.

Willkommen im Forum!

Nachdem sich nebenan niemand zu deinem Beitrag geäussert hat will ich das hier mal tun.

Schön zu sehen das sich jemand für die deutschen Bahnen vor der Konstituierung der DRG interessiert, und das auch gerne in TTD umgesetzt sehen würde. Schön auch dass jemand Eigeninitiative entwickelt. Im Prinzip sind ja nicht nur die durch umfangreiches und vielfältiges Rollmaterial gekennzeichneten preusssischen Bahnen, sondern im besonderen die bayerischen Bahnen, aber auch die anderen Länderbahnen (Sachsen!) sehr interessant.

Diese Meinung ist übrigens nicht Besonderes sondern sozusagen Konsens hier.

Das Problem ist aber ein schlüssiges Konzept dafür wie man jetzt verschiedene, sich ergänzende, Sets anlegen sollte. Dies wurde (und wird) hier bereits ausgiebigst im DBSet XL thread diskutiert.

In Bezug auf v0.9 ist zu sagen dass auf jeden Fall einige frühere Loks eingefügt werden, s. dazu Razzis Ausführungen im DB Set thread. Die von dir gezeigten Wagen sind sogar schon in der derzeitigen Arbeitsversion von 0.9 enthalten.

[betriebliche Parameter]

Gegenüber der Entwicklung eines Gesamtkonzepts sind diese Fragen allerdings ziemlich leicht zu beantworten.

Hier findest du die Spezifikation der nfo-"Sprache" sowie ein mehr oder weniger ausführliches Benutzerhandbuch und einige Programmierbeispiele.

verdennis schrieb:1) Die pr. T2 (und mit ihr die beiden Waggons) soll erst ca. 1880 erscheinen und nicht bereits 1825, wie die "Rocket", die sie grafisch ersetzt.
2) Der Personenwagen sollte in der Lage sein, neben Passagieren alternativ auch Touristen zu befördern.
3) Der Gepäckwagen sollte in der Lage sein, alle ECS-typischen Frachtarten außer Passagiere und Touristen zu transportieren, insbesondere Post.

1) Das Erscheinungsdatum wird mittels einer action0, property 0 bzw 2A eingestellt, s. http://wiki.ttdpatch.net/tiki-index.php?...ion0Trains

2) auch dies wird per action0 eingestellt, diesmal mittels property 1D, hier werden einfach die sog "cargo bits" der zu transportierenden Frachten addiert.

3) desgleichen für den Gepäckwagen. Einfach die Frachtmaske so setzen dass alle gewünschten Frachtarten akzeptiert werden.

Möglicherweise wäre es hilfreich die entsprechenden Zeilen hier zu posten damit dann jemand entsprechende Änderungen vorschlagen kann.

Gruß
Michael

Hallo Michael und alle anderen!

Vielen Dank für die Links und die Hilfestellungen. Die Links kenne ich schon, aber trotzdem werde ich nicht ganz schlau aus ihnen.

Soweit bin ich mittlerweile: Das gewünschte Erscheinungsdatum einiger Fahrzeuge soll ja der 1. Januar 1880 sein. Gemäß der Rechnung 1880 Jahre x 365,25 Tage komme ich auf einen Wert von 686670. Dieser Wert ist also in etwa der 686670. Tag ab Beginn unserer Zeitrechnung und demnach (ungefähr) der 1. Januar 1880, richtig?

Um dieses Datum als Erscheinungsdatum in die nfo-Datei zu schreiben, muss ich dort nach der "Action" 2A und die vier folgenden Doppelzifferwerte suchen. Bei den bislang 1825 erscheinenden Fahrzeugen steht da:

2A D5 2B 0A 00

"2A" und "0A 00" scheint immer gleich zu bleiben, so dass ich diesen Strang folgendermaßen abändern muss:

2A XX XX 0A 00

Wie komme ich nun vom Zahlwert 686670 (~1. Jan. 1880) auf den korrekten Wert für "XX XX"? Da werde ich trotz meiner Englischkenntnisse nicht wirklich schlau draus...

Der von Dir angegebene Link http://wiki.ttdpatch.net/tiki-index.php?...ion0Trains besagt zwar, dass das Datum 1.1.1920 den Zahlenwert 701265 hat und demnach den Strang (2A)"51 B3 0A 00", aber wie ich zu dem für 1880 richtigen Wert komme und was das mit Schaltjahren zu tun hat, kann ich nicht ableiten...

Vielleicht hast Du bzw. jemand anderes in diesem Forum einen Vorschlag? Danke für Hilfen im Voraus,

verdennis.

0A 00 gehört auch zum Datum. Das Datum 1.1.1920 ist der 701265ste Tag, das gibt als Hex Zahl AB351. Daraus machen wir: 00 0A B3 51. Da die Zahlen immer "verkehrt" in die .nfo eingetragen werden müssen, gibt das: 51 B3 0A 00.

Nemen wir das Datum 1.1.1880, ist das der 686670ste Tag.
Als Hex: A7A4E
Ausgeschrieben: 00 0A 7A 4E
Umkehren: 4E 7A 0A 00

Also müsste 2A 4E 7A 0A 00 das Startdatum 1.1.1880 ergeben.


Alternativ kann auch \d<date> eingetragen werden (ab nforenum 3.4.6 und grfcodec 0.9.11), siehe dazu auch hier.

Hallo Addi!

Danke für die Hilfe! Irgendwie komme ich mit dem Hex-Converter vom ttdpatch.net nicht klar, dafür liefert der folgende brauchbare Ergebnisse:

http://www.langeneggers.ch/Nuetzliches/Hex_Dez.htm

Jetzt weiß ich schon mal, wie die Baujahre eingibt, vielen Dank!

Dann kann ich mich ja jetzt an die Frachtartenbestimmung heranwagen...

Schöne Grüße,

verdennis.

wie gesagt, einfach "\d01-01-1880" (oder andersrum) hinschreiben, dann funktioniert das einwandfrei, und man kann auch in nem halben Jahr noch erkennen, was da eigentlich gemeint ist

Ich möchte Eddis Kommentar nochmal unterstreichen, weil es die Lesbarkeit wirklich ENORM erleichtert, sich dieser (und anderer) Escape-Sequenzen zu bedienen:

http://wiki.ttdpatch.net/tiki-index.php?...Byte_order

NewGRF Wiki in Übersetzung: schrieb:Folgende Escape-Sequenzen sind verfügbar:
\b<dec>
\b<year>
\b*<dec>
\w<dec>
\wx<hex>
\w<date>
\d<dec>
\dx<hex>
\d<date>

Wobei:
Der zweite Buchstabe (oder bei \b* die dritten und vierten Buchstaben) zeigt die Anzahl notwendiger Byts an: b steht für ein Byte, b* für ein "extended byte", w für ein word (=2byte), und d für ein dword (=4byte).
<dec> ist eine positive Ganzzahl gegebener Größe
<year> ist ein Jahr; das Resultat ist <year>-1920
<hex> ist eine big-endian hexadecimale Ganzzahl gegebener Größe
<date> ist ein Datum mit einem der vier Formate YYYY-MM-DD, YYYY/MM/DD, DD-MM-YYYY, oder DD/MM/YYYY. In allen Fällen dürfen führende Nullen weggelassen werden.

Ich kann auch nur anraten, die \b \b* \w und \d Escape-Sequenzen für lesbare Zahlen zu verwenden; auch da hilft es, wenn man nicht umrechnen (und sich um little und big endian keine Kopf machen) muß.

Einführungsdatum von Zügen in action0, property 2A werden in Tagen seit 1. Januar 0 gezählt, ähnlich dem julianischen Datum.

(nur hat jemand gepennt, weil es im gregorianischen Kalender gar kein Jahr 0 gibt (springt von -1 auf 1))

Hallo!

An die \d...-Sequenzen traue ich mich so noch nicht heran, zumal ich noch nicht weiß, ob ich z. B. das Erscheinungsdatum anstelle der 4 Doppelziffern nach "2A" eintragen muss oder wo sonst...

Im Moment arbeite ich an der Frachtartenfestlegung:

Gemäß der Frachttabelle in http://wiki.ttdpatch.net/tiki-index.php?page=CargoTypes würden sich die Bit-Values in der Tabelle für den Personenwagen (Passagiere und Touristen) auf 80000001 und für den Gepäckwagen (alle Frachten außer eben Passagiere und Touristen) auf 86666664 summieren.

Durch den Hex-Converter gejagt ergeben sich die Werte 4C4B401 bzw. 52A6DA8. Müsste ich jetzt auch die Werte wie beim Erscheinungsdatum umdrehen und folgendermaßen formulieren: 1D 01 B4 C4 04 bzw. 1D A8 6D 2A 05 ?

Zwar ändert jetzt der Packwagen einige der Frachten, wenn ich das so mache, aber es fehlen immer noch einige, und beim Personenwagen, der bislang noch gar keine 1D...-Sequenz hatte, fehlen weiterhin die Touristen...

Eine Idee? Danke im Voraus, schöne Grüße,

verdennis.

(05.04.2010 23:40)verdennis schrieb:  An die \d...-Sequenzen traue ich mich so noch nicht heran, zumal ich noch nicht weiß, ob ich z. B. das Erscheinungsdatum anstelle der 4 Doppelziffern nach "2A" eintragen muss oder wo sonst...

Ja, das \d ersetzt vier "Doppelziffern", \w entsprechend zwei und \b eine

Zitat:Gemäß der Frachttabelle in http://wiki.ttdpatch.net/tiki-index.php?page=CargoTypes würden sich die Bit-Values in der Tabelle für den Personenwagen (Passagiere und Touristen) auf 80000001 und für den Gepäckwagen (alle Frachten außer eben Passagiere und Touristen) auf 86666664 summieren.

Durch den Hex-Converter gejagt ergeben sich die Werte 4C4B401 bzw. 52A6DA8. Müsste ich jetzt auch die Werte wie beim Erscheinungsdatum umdrehen und folgendermaßen formulieren: 1D 01 B4 C4 04 bzw. 1D A8 6D 2A 05 ?

nein, das sind schon Hex-Werte in der Tabelle, die darf man nicht umrechnen. und 1+2+4+8=F, also müßte es sich zu 7FFFFFFE addieren [= das Gegenteil zu 80000001]. die mußt du jetzt in 2er-Stücke zerlegen und umdrehen, also 01 00 00 80 usw.

@verdennis

Alle Werte in der Spezifikation sind Hex-Werte, ausser Spritenummern und Spritelängen.

Gruß
Michael

Vor den Escape - Sequenzen braucht man eigentlich keine Angst haben. Hier 'mal ein Beispiel am "lebenden" Objekt eines Wagons:

Zitat:// Action 0
762 * 71 00 00 \b26 01 \b*134
// Game related props
02 \b01 // Reliability Decay
03 \b40 // Vehicle Life/Years
04 \b45 // Model Life/Years
05 00 // Track type; 00 Rail, 01 Mono, 02 Mlev
06 07 // Climate availability
07 \b20 // Loading Speed
08 01 // AI Pax optimized

// Physical properties
00 \w1920-01-01 // Intro year \wyyyy-mm-dd
09 \w230 // Wagon speed limit (2 byte in decimal
0B \w0 // Power in HP (2 byte in decimal)
2A \d1960-1-1 // Introyear in days after year 0, with leapyears, except every 400 yrs (year*365,24)
16 \b40 // Weight/Tons (1 byte in decimal)

// Economical properties
14 \b50 // Cargo Capacity (1 byte in decimal)
15 00 // Cargo Type
1D \dx0 // Refit bitmask (4 byte in hex) (KEINE Cargo direkt festlegen)
28 \wx01 // New cargo classes (2 byte in hex) (Nur Cargo Class1 = Passagiere erlauben)
29 \wxFFFB // New NOT Cargo classes (2 byte in hex) (Fast alle anderen Explizit verbieten)
0D \b32 // RUN Cost Factor
0E \dx4C30 // RUN cost Base
17 \b35 // Cost Factor
1C 00 // Refit cost

// Misc
12 FD // Use new grapics (keine Escape sequenz = hex)
19 00 // Traction type (maglev, rail, monorail)
1E FF // Callbacks
21 00 // Shorter vehicle
27 02 // 01 tilt + 02 2cc + 04 xMU

Besonders wichtig an an diesen Beispiel ist wohl die Verwendung von "Cargo Classes". Damit bekommst du automatisch Unterstützung für Touristen, und was sich die NewGRF Autoren sonst noch so ausdenken [Arbeiter, beispielsweise, allerdings halte ich diese Trennung grundsätzlich für ne schlechte Idee. Touristen, Pendler und sonstige Reisende sollten sich die Fahrzeuge teilen können]

Eddi schrieb:[...] Touristen, und was sich die NewGRF Autoren sonst noch so ausdenken [Arbeiter, beispielsweise, allerdings halte ich diese Trennung grundsätzlich für ne schlechte Idee. Touristen, Pendler und sonstige Reisende sollten sich die Fahrzeuge teilen können]

George wollte das damals UNBEDINGT als neue Frachtart für seine Touristenzentren (Neuschwanstein etc) haben. Da er sich davon nicht abbringen liess habe ich im DB Set für einige wenige Züge (VT11.5 etc) zusätzlich zu "Passagieren" auch "Touristen" zugelassen. Besonders dieser Zug wurde ja als "Ferienzug" eingesetzt, was auch immer die DB damit meinte. Ist also "vorbildgerecht", wenn man will.

Gruß
Michael

Hallo!

Vielen Dank für die Tipps und Anregungen, vor allem zu den HEX-Werten! Ich habe die Frachtarten über die 1D-Property festgelegt bzw. diese hinzugefügt, auch wenn die Machart über Property 28 und 29 flexibler ist für einen eventuellen Ausbau von ECS. Leider funktioniert die Schreibweise mit diesen Escape-Sequenzen (z. B. für das Baujahr) doch nicht, wahrscheinlich müsste ich dafür die ganze Datei oder zumindest den Slot mit den Fahrzeug-Funktionsangaben komplett umarbeiten - das wird mir momentan dann doch ein bisschen zu viel...

Es hat nur ein wenig gedauert, bis ich als Laie gemerkt hatte, dass man am Beginn der Slot-Zeile die Anzahl der folgenden Properties festlegen bzw. erhöhen muss, wenn man eine komplett neue hinzufügt...

@ MB: Über den Sinn von Touristen in der ECS-Wirtschaft mag man in der Tat streiten, doch es gibt sie nunmal, und ECS ist momentan das m. E. ausgereifteste Industrieset, und dann sollten sie auch vorkommen dürfen. Auch der aus dem Ausgangsset übernommene Uralt-Bus kann jetzt Touristen transportieren.

Ansonsten ist das Set quasi fertiggestellt: Neben den genannten Änderungen (Frachtarten und Baujahr) habe ich die Ladekapaziäten noch etwas erhöht, den Dampflokrauch genau über den Schornstein justiert und die Lokräder etwas dunkler gemacht (ohne dabei auf einen Grauton zu stoßen, der im Spiel transparent erscheint...). Damit wirken die Loks farblich noch etwas kompatibler zum DB-Set.

Vielleicht mache ich den Bus noch zweifarbig (wie im German-Road-Vehicles-Set) - muss ich dafür nur einen Teil der kotzblauen Sprites in kotzgrün umwandeln, damit man zwei Farben einstellen kann, oder bedarf es auch hier noch Änderungen in der nfo-Datei?

Sofern von den Urhebern der Ausgangsdatei keine Einwände kommen, werde ich die .grf-Datei in Kürze posten, schöne Grüße,

verdennis.

(07.04.2010 00:54)verdennis schrieb:  Es hat nur ein wenig gedauert, bis ich als Laie gemerkt hatte, dass man am Beginn der Slot-Zeile die Anzahl der folgenden Properties festlegen bzw. erhöhen muss, wenn man eine komplett neue hinzufügt...

dazu noch einen wichtigen Tipp: benutze NFO-Renum, das kann dir ziemlich genau sagen, wo derartige Zahlen falsch gesetzt sind. Wenn die Escape-Sequenzen nicht funktionieren, hast du vielleicht eine alte Version von GRFCodec. Die neueste gibt es hier.

Zitat:ECS ist momentan das m. E. ausgereifteste Industrieset

Das würde ich so nicht unterstreichen, da erstens ECS noch den Zusatz "Beta" hat, und zweitens ich PBI für sehr viel ausgereifter halte. [Erstens ist es schon "Final", zweitens wesentlich klarer strukturiert und drittens untereinander und mit dem Original grafisch besser ausgearbeitet]. Nebenbei gibt es noch FIRS als nicht zu verachtende ECS-Konkurrenz. Beim derzeitigen Entwicklungstempo ist das innerhalb des nächsten Jahres locker an ECS vorbeigezogen.

Zitat:[ein] Grauton [...] der im Spiel transparent erscheint...

nee... Transparent ist nur das "Hintergrund-Blau"...

Zitat:Vielleicht mache ich den Bus noch zweifarbig (wie im German-Road-Vehicles-Set) - muss ich dafür nur einen Teil der kotzblauen Sprites in kotzgrün umwandeln, damit man zwei Farben einstellen kann, oder bedarf es auch hier noch Änderungen in der nfo-Datei?

Man muß noch ein Vehicle-Flag setzen, damit das Grün durch die zweite Firmenfarbe ersetzt wird, sonst bleibt es grün.

verdennis schrieb:[nfo-Probleme]
Es hat nur ein wenig gedauert, bis ich als Laie gemerkt hatte, dass man am Beginn der Slot-Zeile die Anzahl der folgenden Properties festlegen bzw. erhöhen muss, wenn man eine komplett neue hinzufügt...

S. einmal hier: http://www.tt-ms.de/forum/showthread.php...6#pid58496

verdennis schrieb:@ MB: Über den Sinn von Touristen in der ECS-Wirtschaft mag man in der Tat streiten, doch es gibt sie nunmal, und ECS ist momentan das m. E. ausgereifteste Industrieset, und dann sollten sie auch vorkommen dürfen.

Ich habe doch selber die Spezifikation von ECS erstellt und letztlich auch "Touristen" dort zugelassen. Also ... Dass man darüber diskutieren, bzw anderer Meinung sein kann, ist ganz normal. Auch mir gefällt diese "Frachtart" nicht. Heute würde ich George dazu drängen "Touristen" als "sub-cargo" von "Passagieren" zu implementieren, aber dieses Feature gab es damals noch nicht.

verdennis schrieb:Ansonsten ist das Set quasi fertiggestellt [...] Sofern von den Urhebern der Ausgangsdatei keine Einwände kommen, werde ich die .grf-Datei in Kürze posten, schöne Grüße,

Du wirst doch nicht ein Set mit lediglich zwei Loks und zwei Wagen in´s Netz freisetzen wollen?! MMn schadet so etwas langfristig mehr als dass es nützt. Es gibt bereits jetzt Hunderte von Mini-Sets von denen niemand weiss was sie genau machen, welche Nebenwirkungen sie haben oder wofür sie überhaupt gut sein sollen. Also davon würde ich dringend abraten.

Gruß
Michael

(07.04.2010 07:36)mb schrieb:  

verdennis schrieb:Ansonsten ist das Set quasi fertiggestellt [...] Sofern von den Urhebern der Ausgangsdatei keine Einwände kommen, werde ich die .grf-Datei in Kürze posten, schöne Grüße,

Du wirst doch nicht ein Set mit lediglich zwei Loks und zwei Wagen in´s Netz freisetzen wollen?! MMn schadet so etwas langfristig mehr als dass es nützt. Es gibt bereits jetzt Hunderte von Mini-Sets von denen niemand weiss was sie genau machen, welche Nebenwirkungen sie haben oder wofür sie überhaupt gut sein sollen. Also davon würde ich dringend abraten.

Es mag sein, dass es genug "Mini-Sets" gibt. Aber im Vergleich zu den Hunderten, bei denen keiner weiß, was sie genau machen, hat das oben genannte ein klares Einsatzfeld: Zusammen mit dem DB-Set zu Beginn des 20. Jahrhunderts oben genannte Fahrzeuge bereitstellen.

pETe! schrieb:

mb schrieb:Du wirst doch nicht ein Set mit lediglich zwei Loks und zwei Wagen in´s Netz freisetzen wollen?! MMn schadet so etwas langfristig mehr als dass es nützt. Es gibt bereits jetzt Hunderte von Mini-Sets von denen niemand weiss was sie genau machen, welche Nebenwirkungen sie haben oder wofür sie überhaupt gut sein sollen. Also davon würde ich dringend abraten.

Es mag sein, dass es genug "Mini-Sets" gibt. Aber im Vergleich zu den Hunderten, bei denen keiner weiß, was sie genau machen, hat das oben genannte ein klares Einsatzfeld: Zusammen mit dem DB-Set zu Beginn des 20. Jahrhunderts oben genannte Fahrzeuge bereitstellen.

Nein, der Einwand trifft auch für dieses Set zu. Es ist nicht das erste Set, dass das DB Set "ergänzen" will, frag´ Bernhard. Auch für andere Sets von mir gibt es "Ergänzungen", die im Einzelfall nicht unbedingt "sinnvoll" sind, aber häufig zusätzliche Probleme schaffen (Schiffskosten-Set zB).

Trotzdem hat aber auch jedes "Mini Set" ein klar definiertes Einsatzfeld. Irgendeine Begründung findet sich ja immer. Zeig´ mir ein einziges Set unter Hunderten was kein "klares Einsatzfeld" hat.

Ich meine dass für ein "preussischen Nebenbahn Set" zwei Loks und zwei Wagen tatsächlich ein bischen mickerig sind.

Und es erhebt sich eben auch die Frage der Kompatibilität. Darüber wurde hier noch kein Wort gesprochen.

Gruß
Michael

Ich meinte, dass das frühe Nebenbahnset alleine Zeitlich vom DBSet so gut wie abgekoppelt ist. Das unterscheidet es von den anderen dir genannten Beispielen.

Ich würde sagen, die Idee eines "Full Sets" ist gut, aber nicht weiter aktuell. Vielleicht sollte man eher über "Design Guidelines" reden, in denen sich eine Erweiterung bewegen könnte. Damit könnten Konflikte zumindest vermieden werden, weil diese ja nicht böswillig erzeugt werden, sondern weil es die Autoren, die "erweiternde" Sets bereitstellen, es u.U. nicht besser wissen. Wenn man ihnen eine Hilfestellung gibt, wird diese sicher wohlwollend angenommen.