DonRazzi schrieb:Dabei fällt mir gerade wieder auf, daß der Transrapid von im DBSet relativ spät kommt, eigentlich ist der ja schon seit Mitte der 1990er serienreif.

s0n!c schrieb:[.] kann ich mir schwer vorstellen das hier ebenfalls einfach nen "texteditor" wie notepad auslangt um z.b. "Lev.4 'Chimaera'" zu "kopieren" und dann die "grunddaten" zu ändern.

Zitat:wenn du mir jetzt noch sagen könntest wo in OTTD ich die bereits "existierenden" fahrzeuge/züge/etc finde

s0n!c schrieb:[.] irgendwo müssen die ganzen daten doch auszulesen/editierbar sein, oder muss ich dazu nen völlig "eigenes" script basteln, das quasi die "originalzüge" (etc) deaktiviert und dafür die "eigenen" aktiviert?

Zitat:wenn ja, dann wirds lustig (alles in englisch und nicht wirklich user-freundlich beschrieben) ^^

Zitat:[.] die wichtigsten daten sind ja über die wiki-links ersichtlich (IDs etc) - bräuchte also nur ne erklärung ala "tu dies und jenes - speicher die datei als abc.def" (also den "start" quasi) - hoffe damit dürfte mir dann geholfen sein für den start

s0n!c schrieb:sehr schön, das ist doch mal eine erklärung wie sie im bilderbuche steht, tausend dank!

Zitat:aber eine frage hätte ich da noch, in dem wiki links die du gepostet hast stand was von namensgebung (unfertiger bereich), das man den "namen" eines fahrzeugs quasi in hexcode einbinden müsse. weisst du wie man nen namen in hexcode ändert? *g*

Zitat:dann zu den fz: wenn ich vorhabe nen "neues" fz zu erstellen, muss ja logischerweise ne neue "ID" her, wie verknüpf ich dann die "neue ID" mit der grafik einer bereits existierenden ID ?

Zitat:XY = meine initialen? sprich ne art "hinweis -> ah, der vogel hats gemacht"? ^^

s0n!c schrieb:/Edit: ok nächstes problem, ich find den eintrag nimmer wo der hexcode für die zeitbestimmung erklärt wurde. wenn ich den windows rechner nutze, dann bekomm ich bei der eingabe von 2000 (jahr) als hex 7D0 raus. wenn ich deine zahl als hex eingebe bekomm ich als dezimal 9074. das passt irgendwie alles nich *wirr*

mit nem hex converter den ich gefunden hab ( http://www.ttdpatch.net/cgi-bin/str2hex.pl?r=00+23+72&Convert=Convert ) schein ich auch nur "text" vernünftig umwandeln zu können. wenn überhaupt, bei eingabe deines datums erhalt ich �#r (00 23 72) bzw #r (23 72) als ergebnis. *wirr*

s0n!c schrieb:/Edit: ok nächstes problem, ich find den eintrag nimmer wo der hexcode für die zeitbestimmung erklärt wurde. wenn ich den windows rechner nutze, dann bekomm ich bei der eingabe von 2000 (jahr) als hex 7D0 raus. wenn ich deine zahl als hex eingebe bekomm ich als dezimal 9074. das passt irgendwie alles nich *wirr*

wiki.ttdpatch schrieb:Date of introduction

The date is specified as number of days since 1920 where TTD counts 365,25 days in a year. [.]

Zitat:D.h. das Einführungsdatum bezieht sich auf den 1.1. 1920. Das Jahr 2000 wäre also 80 Jahre * 365,25 Tage -> 29220 Tage -> 7224h -> "24 72" (LSB = least significant Byte first).

Zitat:GRFCodec version 0.9.10 - Copyright © 2000-2005 by Josef Drexler
Encoding in temporary file test.new
Warning: Found sprite 1 looking for sprite 0.
Warning: Found sprite 2 looking for sprite 1.
Error: Encountered invalid character looking for literal byte.
While reading sprite:1

s0n!c schrieb:zu deinem posting:

Zitat:D.h. das Einführungsdatum bezieht sich auf den 1.1. 1920. Das Jahr 2000 wäre also 80 Jahre * 365,25 Tage -> 29220 Tage -> 7224h -> "24 72" (LSB = least significant Byte first).

da ist mir grad schleiherhaft wie du bei 29220 tagen auf 7224h (stunden?!) kommst. das wären doch 701280std *wirr*

Zitat:sooo, habe jetzt ne testdatei (mit deinem grundaufbau) fertig. da sind garantiert jede menge fehler drin, denn der grfcodec mag die nicht umwandeln ^^

Code:

// Automatically generated by GRFCODEC. Do not modify!
// (Info version 6)
// Format: spritenum pcxfile xpos ypos compression ysize ysize xrel yrel

1 * 4        03 00 00 00
2 * 8        08 06 AK 01 01 00 00    // grf ID
3 * 14       00 00 03 01 00
                        00 23 72               // Jahr 2000
                        09 2C 01            // 300 km/h
                        0E 30 4C 30 FF FF       // 22.224$/Jahr
                        17 04                // 12.496$
                        19 00                // Dampf + vID
                        0B 27 10            // 10000 PS

und hier der fehler, wenn ich den befehl grfcodec -e test.grf eingebe:

Zitat:GRFCodec version 0.9.10 - Copyright © 2000-2005 by Josef Drexler
Encoding in temporary file test.new
Warning: Found sprite 1 looking for sprite 0.
Warning: Found sprite 2 looking for sprite 1.
Error: Encountered invalid character looking for literal byte.
While reading sprite:1

und nu? ^^

mb schrieb:Ahja. "h" bedeutet natürlich nicht "Stunden" sondern "hex", d.h. "7224" ist die hexadezimale Form von "29220" (dezimal). (Alle Zahlen in .nfo/.grf müssen in Hex angegeben werden, ausser die Zeilennummern.)

Zitat:

Code:

2 * 21       00 00 05 01 00
                        00 23 72           // 2000
                        09 2C 01           // 300 km/h
                        0B 27 10           // 10000 PS
                        0E 30 4C 00 00     // (cost = Dampf)
                        17 04              // Preis = 12.496$

statt

Code:

2 * 21 00 00 05 01 00 09 2C 01 0E 30 4C 00 00 00 23 72 17 04 0B 27 10

s0n!c schrieb:warum wurd aus dem "2 * 14" nun ein "2 * 21" ? welchen bezug zieht die zahl (14 bzw 21) ? meine vermutung wäre im moment diese, das es die anzahl der "nummernblöcke" (hex codes(bytes?!)) angibt, die folgen, richtig?

Zitat:sagtest du nicht das alle zahlenangaben im LSB eingetragen werden müssen? laut rechner ergibt 10.000ps = 2710h. last byte first = 1027. nehme an ist nen zahlendreher in deinem beispiel, oder?