Login

Treeman · 25.04.2011, 13:08

Hallo,

gibt es eine Möglichkeit beim DBSetXL die Frachtkapazitäten der einzelnen Waggons zu ändern? Vor allem geht es mir um den Rungenwagen, 15 t Metall auf einem 6-Achser sind weder angenehm noch realistisch. Ein erster Versuch mit Hex-Editor erwies sich als nicht durchführbar...

Besten Dank!

mb · 25.04.2011, 13:21

Treeman schrieb:gibt es eine Möglichkeit beim DBSetXL die Frachtkapazitäten der einzelnen Waggons zu ändern? Vor allem geht es mir um den Rungenwagen, 15 t Metall auf einem 6-Achser sind weder angenehm noch realistisch. Ein erster Versuch mit Hex-Editor erwies sich als nicht durchführbar...

Schalte einfach wagonspeedlimits ein und du bekommst mehrere Generationen von Gü-wagen mit sukzessive höheren Beladekapazitäten.

Gruß
Michael

Eddi · 25.04.2011, 14:15

Also erstens gibt es gar keine Sechsachser im DBSetXL, sondern nur Zwei- und Vierachser (lt. Readme), zweitens laden die Letzteren bei mir 25t Metall, und drittens kannst du mittels GRFCodec die Werte ändern, sähe dann ungefähr so aus:

Code:
// GRF-Header
// (Info version 7)
// 
   -1 * -1	 00 00 00 00 // Anzahl Sprites, wird von NFOrenum ausgefüllt
   -1 * -1	 08 07 <GRFID> <GRFTitel> 00 <GRFBeschreibung> 00 // denk dir was aus
   -1 * -1	 00 08 01 01 00 11 <GRFID> 6D 62 04 01 // "Ich will Wagen des DBSetXL verändern"
   -1 * -1	 00 00 01 01 <Wagen-ID> 14 <Kapazität> // Wagen-ID findest du in der Readme, alle Angaben in HEX
// letzte Zeile für jeden gewünschten Wagen wiederholen

Das Ganze einmal durch NFOrenum und GRFcodec jagen, zum Spiel hinzufügen, fertig.

Treeman · 25.04.2011, 16:26

Besten Dank für die schnelle Antwort.

Wie es sich für einen anständigen DAU gehört, fehlte im ersten Posting wieder mal die Hälfte, in diesem Fall in die Information, dass neben dem DBSetXL auch noch FIRS (und damit logischerweise auch dbxl_firs.grf) im Einsatz ist. Wenn ich es richtig verstanden habe, sollte dies an der beschriebenen Lösung aber wenig ändern.

Ich gebe nforenum folgendes zu futtern:

Code:
/// GRF-Header
// (Info version 7)
//
   -1 * -1     00 00 00 00 // Anzahl Sprites, wird von NFOrenum ausgefüllt
   -1 * -1     08 07 43 43 61 70 4D 6F 64 00 43 61 70 4D 6F 64 00 // ID = 67 (43 Hex) Name sowie Beschreibung = CapMod (43 61 70 4D 6F 64)
   -1 * -1     00 08 01 01 00 11 43 6D 62 04 01 // "Ich will Wagen des DBSetXL verändern"
   -1 * -1     00 00 01 01 41 14 28 // Wagon ID = 41 (Hex):Kapazität = 40 (28 Hex)
//

er spukt mir folgendes wieder aus:

Code:
// Automatically generated by GRFCODEC. Do not modify!
// (Info version 4)
// Format: spritenum pcxfile xpos ypos compression ysize xsize xrel yrel
    0 * 4	 03 00 00 00
/// GRF-Header
// (Info version 7)
//
//   -1 * -1     00 00 00 00 // Anzahl Sprites, wird von NFOrenum ausgefüllt
//!!Warning (219): There was no Action 14 specifying the palette.
    1 * 17	 08 07 43 43 61 70 4D 6F 64 00 43 61 70 4D 6F 64 00 // ID = 67 (43 Hex) Name sowie Beschreibung = CapMod (43 61 70 4D 6F 64)
//!!Fatal Error (64): Expected more data for prop 11. (4 bytes at 10.)
    2 * 11	 00 08 01 01 00 11 43 6D 62 04 01 // "Ich will Wagen des DBSetXL verändern"
    3 * 7	 00 00 01 01 41 14 28 // Wagon ID = 41 (Hex):Kapazität = 40 (28 Hex)
//

da bin ich jetzt wieder mit meinem Latein am Ende, jeder Tip willkommen.

Eddi · 25.04.2011, 16:37

Die GRF-ID muß genau 4 Zeichen (Buchstaben ("ABCD") oder Hex-Werte (01 02 03 04)) umfassen, und so gewählt werden, daß kein anderer auf die gleiche Idee kommen sollte Zwinkern

Die GRF-Beschreibung kannst du ruhig als Zeichenkette ausschreiben Zunge

Treeman · 25.04.2011, 17:17

Auch wenn es mir langsam peinlich wird...

in nforenum geht Folgendes rein:

Code:
// Automatically generated by GRFCODEC. Do not modify!
// (Info version 7)
// Format: spritenum pcxfile xpos ypos compression ysize xsize xrel yrel //Hinzugefügt, da nforenum sonst meckert "Does not appear to be an nfo file"
   -1 * -1     00 00 00 00 // Anzahl Sprites, wird von NFOrenum ausgefüllt
   -1 * -1     08 07 1A 1B 1C 1D 43 61 70 4D 6F 64 00 43 61 70 4D 6F 64 00 // GRF-ID = 1A 1B 1C 1D, Rest wie gehabt
   -1 * -1     00 08 01 01 00 11 1A 1B 1C 1D 6D 62 04 01 // "Ich will Wagen des DBSetXL verändern"
   -1 * -1     00 00 01 01 41 14 28 // Wagon-ID = 41, Kapazität = 28
// letzte Zeile für jeden gewünschten Wagen wiederholen

und ich erhalte das hier zurück (und das ohne fatal error)

Code:
// Automatically generated by GRFCODEC. Do not modify!
// (Info version 7)
// Escapes: 2+ 2- 2< 2> 2u< 2u> 2/ 2% 2u/ 2u% 2* 2& 2| 2^ 2sto = 2s 2rst = 2r 2psto 2ror = 2rot 2cmp 2ucmp 2<< 2u>> 2>>
// Escapes: 71 70 7= 7! 7< 7> 7G 7g 7gG 7GG 7gg 7c 7C
// Escapes: D= = DR D+ = DF D- = DC Du* = DM D* = DnF Du<< = DnC D<< = DO D& D| Du/ D/ Du% D%
// Format: spritenum pcxfile xpos ypos compression ysize xsize xrel yrel
    0 * 4	 03 00 00 00
//   -1 * -1     00 00 00 00 // Anzahl Sprites, wird von NFOrenum ausgefüllt
//!!Warning (219): There was no Action 14 specifying the palette.
    1 * 20	 08 07 1A 1B 1C 1D 43 61 70 4D 6F 64 00 43 61 70 4D 6F 64 00 // GRF-ID = 1A 1B 1C 1D, Rest wie gehabt
    2 * 14	 00 08 01 01 00 11 1A 1B 1C 1D 6D 62 04 01 // "Ich will Wagen des DBSetXL verändern"
    3 * 7	 00 00 01 01 41 14 28 // Wagon-ID = 41, Kapazität = 28
// letzte Zeile für jeden gewünschten Wagen wiederholen

Wenn ich jetzt jedoch versuche, das ganze durch grfcodec zu jagen

-> grfcodec.exe -e CapMod (der Name der Datei mit der Ausgabe von nforenum)

sagt er mir "Cannot read sprites/CapMod.nfo: No such file or directory"

Die Datei "CapMod" einfach in "CapMod.nfo" umbenennen hat nichts gebracht, selbe Fehlermeldung.

Nochmals besten Dank!

Nachtrag
Der Herr ist etwas wählerisch, was seine Verzeichnise anbelangt:
Ich hatte die Datei "CapMod" im Verzeichnis, wo auch die grfcodec.exe lag. Der Trick bestand jetzt darin ein Unterverzeichnis "sprites" anzulegen und die CapMod-Datei unter dem Namen CapMod.nfo dort hinzukopieren.

Eddi · 25.04.2011, 17:28

versuch mal "grfcodec.exe -e CapMod ." (der Punkt ist wichtig)

Nachtrag: wo MB gerade mal da ist: ich hab gerade beim durchtesten festgestellt, daß der schnelle offene Güterwagen (ID: 3B) im alpinen Klima nicht auftaucht, hat das nen Grund?

mb · 25.04.2011, 18:02

Eddi schrieb:[...] ich hab gerade beim durchtesten festgestellt, daß der schnelle offene Güterwagen (ID: 3B) im alpinen Klima nicht auftaucht, hat das nen Grund?

Das liegt vermutlich daran dass dort als default cargo eine Fracht definiert wurde die im AlpineClimate (== arctic!) nicht vorkommt. Die originale TTD-KI konnte früher[tm] nicht umrüsten, und daher hat im DBXL 0.82 jeder Wagen eine andere default-Fracht (damit für die KI immer eine Transportmöglichkeit zur Verfügung steht).

Oder so, ohne in den Code zu schauen. (Kann ich aber heute abend mal tun.)

Gruß
Michael

Treeman · 26.04.2011, 09:42

Nochmal besten Dank an alle für die schnellen und hilfreichen Antworten.

Da der Autor des DBSets ja hier mitliest, nochmal mein Problem in genau:

Die Rungenwagen haben in der Kombination DBSetXL / FIRS-Erweiterung eine Kapazität von 30 Kisten Warenkisten. Rüstet man sie jetzt auf Holz / Metall um schlägt da ein Faktor 0,5 zu, was auf 15t hinausläuft. Und das kommt mir irgendwie etwas wenig vor.

mb · 26.04.2011, 10:18

Treeman schrieb:Die Rungenwagen haben in der Kombination DBSetXL / FIRS-Erweiterung eine Kapazität von 30 Kisten Warenkisten. Rüstet man sie jetzt auf Holz / Metall um schlägt da ein Faktor 0,5 zu, was auf 15t hinausläuft. Und das kommt mir irgendwie etwas wenig vor.

Der (frühe) Rungenwagen hat in der Tat ein Ladegewicht von 15 Tonnen. Da TTD intern das Gewicht einer "Warenkiste" mit 1/2 Tonne berechnet, werden nach dem Umrüsten aus 15 Tonnen Stahl/Holz/Erz eben 30 "Warenkisten".

Das ist also vom Spiel so gewollt, genauso wie die internen Umrechnungsfaktoren für "Wertsachen", "Post", oder "Passagiere".

Durch Verwenden von "callbacks" kann man die Anzahl bzw das Gewicht der umzurüstenden Güter anders bestimmen, aber eben nicht in der Kombination von DBXL und FIRS-Erweiterung, da dafür eben eine direkte Änderung im DBXL (nämlich Einbau der notwendigen callbacks) erfolgen müsste.

Ich sehe hier aber das Problem überhaupt nicht, denn was ist daran unverständlich wenn eine "Kiste" 500 kg wiegen soll? Zudem bereits 1930 ein weiterer Rungenwagen mit 25 Tonnen Ladegewicht zur Verfügung steht?

In DBXL 0.9 benutze ich übrigens für die geschlossenen Güterwagen für einige (leichte) Güter Staufaktoren, zB für "Wolle", wo in einen Gm bestimmt keine 15 Tonnen hineinpassen. Cool

Gruß
Michael

DanielNHG · 26.04.2011, 14:28

Und wenn dann noch die Samms Wagen dazukämen,wo 60 Tonnen Ladung draufpassen....das wäre ein Traum Zunge

Treeman · 26.04.2011, 16:38

(26.04.2011, 10:18)mb schrieb: Ich sehe hier aber das Problem überhaupt nicht, denn was ist daran unverständlich wenn eine "Kiste" 500 kg wiegen soll? Zudem bereits 1930 ein weiterer Rungenwagen mit 25 Tonnen Ladegewicht zur Verfügung steht?

Auch auf die Gefahr hin, das Thema jetzt tod zu diskutieren.

Folgender Versuchsaufbau:
-> OpenTTD 1.1.0
-> DBSetXL 0.82
-> FIRS 0.64
-> aktuelles DBSetXL für FIRS GRF
-> sonst nix

Der letzte Rungenwagen den ich kriege wiegt 11t leer und 26t voll. (Vmax = 120 km/h).

Beste Grüße

Eddi · 26.04.2011, 16:48

Also ich weiß nich, was da bei dir verkehrt läuft, aber bei mir wiegt der 11t leer und 41t voll, und hat 30t Metall Kapazität.

Treeman · 26.04.2011, 18:50

Bei mir liegt Problem liegt offenbar bei der DBXL FIRS extension (ist frisch installiert). Sobald diese aktiviert ist, wird die Kapazität der Rungenwagen konsequent durch 2 geteilt. Aus den 25t werden 12t, aus den 30t 15t. Ohne FIRS und DBXL FIRS extension ist alles so wie in Tabelle aus dem Readme vorgesehen.

Eddi · 26.04.2011, 19:01

dann versuch mal stattdessen dieses hier: http://www.tt-ms.de/forum/showthread.php...0#pid72910

mb · 26.04.2011, 20:52

Ich denke das Problem ist die zwingende Verwendung von "first refittable cargo type" (MENU bzw FF) als default cargotype:

Code:
// [41] Rungenwagen 1970
// GOOD, WOOD, STEL, WDPR, BDMT
definevehicle(_STAKE2, {""},
	cargotype(MENU)
	cargoclasses(+PGOODS, -EXPRESS)   // keine Früchte/Gemüse, ENSP, MNSP, FMSP
	cargomask(GOOD, LVST, WOOL, FICR) // plus Waren; kein Vieh, Wolle, Faserstoffe
)

Abhängig davon ob nun "Waren" oder eines der in Tonnen definierten Schüttgüter als "erstes" vorhanden ist, werden unterschiedliche Werte für die Lademenge angezeigt.

In der FIRS (bzw ECS) extension werden die Kapazitäten jedenfalls nicht verändert.

Gruß
Michael

mb · 27.04.2011, 11:38

Nachtrag:

Hier wurde das Problem schon, in etwas anderem Zusammenhang, erörtert.

Erklärung: "Waren" hat (in FIRS definiert) eine niedrigere slot-Nummer als die Stückgüter die nach Gewicht spezifiziert werden (zB "Metall"). Und daher wird auch die Kapazität für "Waren" (30) angenommen. Diese wird nun allerdings nicht als "Tonnen" sondern als "crates" (die interne Einheit für "Waren) interpretiert. Beim Umrüsten auf "Metall" wird die Kapazität dann auch folgerichtig durch 2 dividiert (-> 15 Tonnen).

Lösung: keine.

Gruß
Michael

Login
Benutzername:
Passwort:	Passwort vergessen?
	Merken

Möglicherweise verwandte Themen…
Thema		Verfasser	Antworten	Ansichten	Letzter Beitrag
	DBSetXL v0.82 max Geschwindigkeit von Güterwagen	grzechura	5	5.109	20.10.2008, 07:35 Letzter Beitrag: grzechura
	Problem mit DBSetXL und Magnetschwebebahn	PATRICKausHH	1	2.038	12.09.2007, 22:45 Letzter Beitrag: mb
	MiniIn r8285 und DBSetXL 0.82	Tusor	7	3.750	06.02.2007, 19:16 Letzter Beitrag: Tusor
	DBsetxl - Problem mit ersetzen	Büsi	2	2.215	19.12.2006, 12:33 Letzter Beitrag: ramstein7
	DBsetXL keine Fernverkehrswagen	Thomaxs	3	2.183	29.09.2006, 14:52 Letzter Beitrag: Bernhard

Baumstrukturmodus \| Linearer Modus Frachtkapazitäten andern (DBSetXL)
Verfasser	Nachricht