Ich hab mal mit Frosch über dbxl_firs et al. diskutiert, dabei ist folgendes herausgekommen:
Zitat:OpenTTD: frosch * r22316 /trunk/src/newgrf.cpp: -Fix: [NewGRF] When determining refittability use the cargo translation table of the GRF setting the refitmask instead of the GRF defining the action 3.
Eddi schrieb:[-Fix: [NewGRF] When determining refittability use the cargo translation table of the GRF setting the refitmask instead of the GRF defining the action 3.]
Der vorige Stand würde ja an sich bei der derzeitigen Strukturierung der Erweiterungen kein Problem darstellen. Das eigentliche Problem ist Andy der mit seinen ewigen Änderungen und durch Nichteinhaltung seiner eigenen Spezifikation den Entwicklern die seinen Set unterstützen wollen das Leben unnötigerweise schwer macht.
Gruß
Michael
Ja, Andy ist manchmal sehr schnell dabei, Ideen in Entscheidungen umzusetzten. Aber darum geht es ja eigentlich nicht.
Jedenfalls kann man jetzt in einem Zusatz-GRF wie dbxl_ecs oder dbxl_firs eine "cargo translation table" (CTT) benutzen.
Ich hab das mal für mich selbst zusammengetüdelt, dabei hab ich die CTT so zurechtgefummelt, daß die Güter ungefähr nach Klassen sortiert sind, dadurch werden die Refitmasken übersichtlicher.
Code:
29 * 126 00 08 01 1E 00 09
"STEL" "WOOD" "MNSP" "WDPR"
"WOOL" "FICR" "FRVG" "RSGR"
"CLAY" "SAND" "GRVL" "GRAI"
"COAL" "IORE" "AORE" "SCRP"
"RCYC" "OIL_" "RFPR" "PETR"
"MILK" "FOOD" "BEER" "FISH"
"BDMT" "GOOD" "FMSP" "ENSP"
"MAIL" "LVST"
//1st gen (1920-1930)
30 * 10 00 00 01 01 1D 1D \dx0301FFFF //LOW: COAL GOOD GRAI WOOD IORE STEL RSGR FRVG WOOL CLAY SAND MNSP WDPR SCRP FICR GRVL AORE BDMT RCYC
31 * 10 00 00 01 01 1E 1D \dx057E0004 //TANK: OIL_ RFPR PETR BDMT MILK FOOD BEER FMSP
32 * 10 00 00 01 01 1F 1D \dx3FF00000 //BOX: MAIL LVST GOOD MNSP FMSP ENSP MILK FOOD FISH BEER BDMT
//2nd gen (1930-1950)
33 * 10 00 00 01 01 20 1D \dx2FF00004 //BOX = BOX: - MAIL
34 * 10 00 00 01 01 21 1D \dx0001FFC0 //GOND = LOW: - GOOD WOOD STEL WOOL MNSP WDPR FICR BDMT
35 * 10 00 00 01 01 22 1D \dx0001FFC0 //LOW = GOND
36 * 10 00 00 01 01 23 1D \dx00007E00 //HOP: COAL GRAI IORE SAND GRVL AORE
37 * 10 00 00 01 01 24 1D \dx0300003F //STA: GOOD WOOD STEL WOOL MNSP WDPR FICR BDMT
38 * 7 00 00 01 01 25 06 00 //ARM (disabled)
//3rd gen (1950-1980)
39 * 10 00 00 01 01 2E 1D \dx00F00000 //RFG: MILK FOOD FISH BEER
40 * 7 00 00 01 01 2F 06 00 //CAR (disabled)
41 * 10 00 00 01 01 31 1D \dx0C000000 //FLAT: FMSP ENSP
42 * 10 00 00 01 01 32 1D \dx03000004 //SLID = BOX: - LVST MILK FOOD FISH FMSP ENSP BEER
43 * 7 00 00 01 01 33 06 00 //CONT (disabled)
44 * 13 00 00 02 01 34 1D \dx057E0000 00 45 0E //TANK (1930) = TANK
45 * 10 00 00 01 01 35 1D \dx03000004 //TARP = SLID
//4th gen (1980-2010)
46 * 6 07 85 01 \70 5D 01 // only with speedlimits
47 * 10 00 00 01 01 3B 1D \dx0001FFC0 //HIGH = GOND
48 * 10 00 00 01 01 3C 1D \dx23000004 //BOX (1950) = SLID: + LVST
49 * 10 00 00 01 01 3D 1D \dx057E0000 //TANK = TANK
50 * 10 00 00 01 01 3F 1D \dx00007E00 //HOP = HOP
51 * 10 00 00 01 01 40 1D \dx00F00000 //RFG = RFG
52 * 10 00 00 01 01 41 1D \dx0300003F //STA = STA
53 * 10 00 00 01 01 42 1D \dx0C000000 //FLAT = FLAT
Eddi schrieb:Ja, Andy ist manchmal sehr schnell dabei, Ideen in Entscheidungen umzusetzten. Aber darum geht es ja eigentlich nicht.
Hier nicht, aber dies ist im Moment tatsächlich das einzige "Problem" was ich diesbzgl sehe.
Denn
Eddi schrieb:Jedenfalls kann man jetzt in einem Zusatz-GRF wie dbxl_ecs oder dbxl_firs eine "cargo translation table" (CTT) benutzen.
dies ist ja mehr oder weniger irrelevant, da sowohl dbxl_ecs als auch dbxl_firs die cargo bits direkt nutzen. Der einzige Vorteil wäre das nun eine einzige Erweiterung (mittels einer CTT) für beide Gütersets benutzt werden könnte, wie ich es anfangs vorhatte. Und was in 0.9 ohnehin geschieht.
Ich sehe hier also keinen wirklichen Handlungsbedarf.
Dagegen, wie gesagt, sehe ich Handlungsbedarf bzgl FIRS, denn zB die Wiedereinführung von BEER dort kollidiert mit der Behandlung von "flüssigen Nahrungsmitteln" in ECS, zB "food(beer)" in kaum lösbarer Weise. Dort wurde BEER ja gerade abgeschafft, nun wird es wieder eingeführt ... Da diese Feinheiten durch noch so geschickten Aufbau einer CTT nicht (ist Fz-Set abhängig) gelöst werden können, droht der grösstmöglich anzunehmende Verdruss von Güterset-spezifischen CTTs. Etwas was jeder vernünftige Entwickler unterlassen sollte.
Gruß
Michael
kommt am 3. juni eigentlich die demo-version vom 0.9? bei duke nukem soll das angeblich so sein
und bekommen wir den icx schon eher als die deutsche bahn?
das wäre doch mal was!
ICx ist ein "langsamer ICE" als IC-Ersatz, die Doppelstockwagen sind damit nicht gemeint.
wo hast du den denn her? fährt der auch 180?
der icx soll in der ersten ausführung 230, in der zweiten 249km/h fahren und damit ice1 und 2 ersetzen. also genaugenommen 2 züge, wo man nur einen malen muss...
Der kommt nicht von mb und ist somit nicht im DBXL ...
Der ist von Bernhard...du musst ihn fragen ob du ihn bekommst...
ja, ich müsste mich mal an die finale Version setzen... keine Zeit
Ich habe gerade auch keine, aber in 3 Wochen sind Pfingstferien
donniex schrieb:[...] bekommen wir den icx schon eher als die deutsche bahn?
Haben die Bahngötter schon irgendwas verlauten lassen über die Baureihenbezeichnung(en)?
Und "24 verschiedene Zugkombinationen" sind auch irgendwie lästig ...
[
attachment=3970]
Gruß
Michael
(22.05.2011 13:34)mb schrieb: [ -> ]donniex schrieb:[...] bekommen wir den icx schon eher als die deutsche bahn?
Haben die Bahngötter schon irgendwas verlauten lassen über die Baureihenbezeichnung(en)?
Und "24 verschiedene Zugkombinationen" sind auch irgendwie lästig ...
![[Bild: attachment.php?aid=3970]](http://www.tt-ms.de/forum/attachment.php?aid=3970)
Gruß
Michael
Folgerung: Eher nein ...?!
Yoshi schrieb:Folgerung: Eher nein ...?!
Was, "eher nein"?
In 0.9 sind ja alle nun Triebzüge (bis auf den VT08) in fester Konfiguration erhältlich. Man könnte also lediglich die beiden Grundkonfigurationen (K1, K3) des ICx anbieten. Oder auch die zusätzlichen 4 "zugelassenen" Konfigurationen [*]. Oder eben alle 24. Das wäre aber wohl gleichbedeutend mit "freier Konfiguration".
Ansonsten macht der ICx keine Probleme. Man ist ja froh über jedes neue Rollmaterial der DB.
[*] "views" für Züge wurde ja leider nicht als sinnvoll anerkennt.
Gruß
Michael
(22.05.2011 13:56)mb schrieb: [ -> ]"views" für Züge wurde ja leider nicht als sinnvoll anerkennt.
Das wäre was für die Flirts und andere...
Hm. Wäre es bei dem ICx dann nicht sinvoll, tatsächlich frei Konfiguration zuzulassen und nicht gleich den kompletten Triebzug zu kaufen? Ich gebe hier zu bedenken, dass der Zug ja auch langsamer sein wird, als etwa der ICE 3, wodurch es anderer Vorteile bedarf, um ihn sinnvoll ins Spiel zu integrieren.
Grüße,
DonRazzi
DonRazzi schrieb:[...] Ich gebe hier zu bedenken, dass der Zug ja auch langsamer sein wird, als etwa der ICE 3, wodurch es anderer Vorteile bedarf, um ihn sinnvoll ins Spiel zu integrieren.
In der Tat. Das allein schon wird die meisten davon abhalten ihn überhaupt verwenden zu wollen.
MMn ist es am sinnvollsten den ICx (wie die DB auch, "Realismus" lass´ nach ..) als Ersatz für lokbespannte ICs einzusetzen, und für die Langstrecken den vorhandenen ICE-3 weiter zu nutzen. Man muss dann mal so lange an der Kosten/Nutzen Relation drehen bis das irgendwie passt. Und dazu gehört natürlich auch die Konfiguration des Zugs.
PS: lange nicht gelesen.
Gruß
Michael
wie sieht es denn mit den ICE4 aus (ich hoffe ich hab jetzt nichts überlesen)? wird der auch in der nächsten Version vertreten sein?
gruß robo
Ist sowas überhaupt schon in ner brauchbaren Planungsphase?
(24.05.2011 14:27)robotron schrieb: [ -> ]wie sieht es denn mit den ICE4 aus (ich hoffe ich hab jetzt nichts überlesen)? wird der auch in der nächsten Version vertreten sein?
gruß robo
Meines Wissens nach ist der ICx als Ersatz für IC-Linien und langsame ICE-Linien (z.B. Frankfurt-Dresden) geplant, die Geschwindigkeit wurde vornehmlich aus Kostengründen in Bezug auf die Erfüllung von EU-Vorgaben gewählt.
Über einen Ersatz für die schnellen ICE-Linien ist mir bisher nichts bekannt.