Eddi schrieb:Und 99% der Zielgruppe werden auch dieses Feature benutzen, damit wirst du einfach leben müssen.

Ich glaube die Zielgruppe sind Leute, die das DB-Set als "full set" nutzen wollen. Die tatsächlichen Nutzer mögen andere Sein, das bedeutet jedoch nicht, dass diese zur Zielgruppe gehören.

Also erstens ist die Einstellung per Default an, also werden erstmal allein schon deswegen die meisten neuen Nutzer daran nix ändern.

Und zweitens ist es, wie in meinem Fall, wesentlich häufiger, daß die Leute Straßenfahrzeugsets mischen wollen (z.B. Long Vehicles mit einem Straßenbahnset, oder HEQS, welches nahezu jedes normale Straßenset sinnvoll erweitert), und die Möglichkeit, auch mehrere Zugsets zu benutzen, gar nicht benötigt wird.

Das Problem ist wohl dass das dies früher[tm] standardmässig "aus" war, aber mittlerweile "an" sein soll. Unverständlich, wie so manches.

Ich habe hier übrigens noch weitere Probleme mit der Frachtzuordnung, die ich nicht verstehe. Im Prinzip ist dbxl_firs ja nichts anderes als eine modifizierte dbxl_ecs, lediglich mit anderen Frachtbits und ohne dessen TTDPatch-KI Sektion, aber es funktioniert nicht richtig. Es werden zB "Nahrungsmittel" für Wagen angezeigt, für die dieses Bit explizit nicht gesetzt ist, etc.

Gruß
Michael

(08.06.2010, 15:39)Michael schrieb: Das sieht so aus als hättest du dieses "multipool" Misfeature aktiv?

Jo jetzt geht es! Hätte nicht damit gerechnet.

EDIT: Vielen Dank MB!!!
Du hast mich dazu bewogen, dass erste mal FIRS richtig zu spielen...

Ich hab es auch mal angeguckt und firs.grf mit dem overide gepatched, falls du das nicht in deinen GRFs möchtest, wäre das problemlos bei FIRS unterzubringen, denke ich mal.

Dabei fiel mir folgendes auf:
- kein FarmSupplies wagons
- Food mit low side und stake wagon
- Fuel Oil mit Goods Vans (oder Flat bed)
- keine ManufacturSupplies wagons
- Sand auch im TransRapid
das ist mit FIRS r896M (M für override patch)

Hmm, böse gesagt, das ECS Extension für FIRS gefällt mir besser.

Edit: Wenn du möchtest, könntest du auch die Sourcen vom ECS oder FIRS Extension publizieren, vielleicht könnte man dann mittels Patch Vorschläge unterbreiten..

Grüsse
Ammler

Ammler schrieb:Ich hab es auch mal angeguckt und firs.grf mit dem overide gepatched, falls du das nicht in deinen GRFs möchtest

Wenn ich schon eine grf exklusiv für OTTD zusammenstelle dann kann ich das auch noch einbauen.

Ich hatte allerdings zunächst vermutet dass es auch ohne, so wie bei dbxl_ecs, funktionieren würde.

Ammler schrieb:Dabei fiel mir folgendes auf:
[...]
- Food mit low side und stake wagon

Das (und anderes) war mir auch schon aufgefallen:

   

Ich kann das aber nicht nachvollziehen, denn


die Frachtbitmaske ist korrekt.

Gruß
Michael

(08.06.2010, 17:27)mb schrieb: Ich hatte allerdings zunächst vermutet dass es auch ohne, so wie bei dbxl_ecs, funktionieren würde.

Der Override von dbset_ecs ist mit openttd[d|w].grf definiert.

Gruess
Ammler

Ammler schrieb:Der Override von dbset_ecs ist mit openttd[d|w].grf definiert.

Schon klar. Aber woher sollte man das wissen?

Trotzdem hatte ich (s. Antwort an Eddi) geahnt woran es liegen könnte.

Ich hab´ das jetzt mal eingebaut.


Aber trotzdem ist da noch irgend etwas an der Frachtzuordnung faul ...

Gruß
Michael

Also... die tiefen Details entziehen sich mir hier vielleicht, aber mein Verständnis von der Situation ist diese:

Das Spiel merkt sich, daß das Fahrzeug vom dbsetxl definiert wird (Action 3).

Bei der Auflösung der Refitmaske wird nun das GRF des Fahrzeugs befragt, also dbsetxl. Dort gibt es aber keine Cargo Translation Table, weshalb die Auflösung gemäß der Cargo-ID benutzt wird, während die Cargo Translation Table aus dbxl_firs ignoriert wird. Das funktionierte also nur rein zufällig in dbxl_ecs, weil die Güter in der gleichen Reihenfolge standen.

Hmm, wurde hier eigentlich schon mal ein Link zur "finalen" NFO gepostet?
http://bundles.openttdcoop.org/firs/nigh...T/firs.nfo

Eddi schrieb:[...] Das Spiel merkt sich, daß das Fahrzeug vom dbsetxl definiert wird (Action 3).

Bei der Auflösung der Refitmaske wird nun das GRF des Fahrzeugs befragt, also dbsetxl. Dort gibt es aber keine Cargo Translation Table, weshalb die Auflösung gemäß der Cargo-ID benutzt wird, während die Cargo Translation Table aus dbxl_firs ignoriert wird. Das funktionierte also nur rein zufällig in dbxl_ecs, weil die Güter in der gleichen Reihenfolge standen.

Nach meinem Verständnis sollte die ursprüngliche Frachtmakse, genauso wie alle anderen action0 properties, durch die nachfolgend geladene grf überschrieben werden. Ich habe das Gefühl das dies in OTTD hier nicht richtig funktioniert.

Die CTT ihrerseits ist ja gerade für derartige Zwecke (grf-übergreifend) da. Die Anordnung der labels in der CTT hat übrigens keinen Einfluss auf das falsche Verhalten, damit habe ich gestern abend einige Zeit verbracht.

Ich werde heute abend nochmal eine "fake" FIRS grf für TTDPatch erzeugen und das Verhalten dort überprüfen.

Die Masken bits für die verwendete CTT sind alle soweit korrekt.

Gruß
Michael

(08.06.2010, 18:52)mb schrieb:

Eddi schrieb:[...] Das Spiel merkt sich, daß das Fahrzeug vom dbsetxl definiert wird (Action 3).

Bei der Auflösung der Refitmaske wird nun das GRF des Fahrzeugs befragt, also dbsetxl. Dort gibt es aber keine Cargo Translation Table, weshalb die Auflösung gemäß der Cargo-ID benutzt wird, während die Cargo Translation Table aus dbxl_firs ignoriert wird. Das funktionierte also nur rein zufällig in dbxl_ecs, weil die Güter in der gleichen Reihenfolge standen.

Nach meinem Verständnis sollte die ursprüngliche Frachtmakse, genauso wie alle anderen action0 properties, durch die nachfolgend geladene grf überschrieben werden. Ich habe das Gefühl das dies in OTTD hier nicht richtig funktioniert.

Also Frosch meinte, TTDPatch verhalte sich da genauso, ausschlaggebend ist die Action 3.

Zitat:Die CTT ihrerseits ist ja gerade für derartige Zwecke (grf-übergreifend) da.

jein, CTT sind dazu da, Cargos GRF-übergreifend zu benutzen, die CTT selbst ist nicht grf-übergreifend. Da jedes GRF eine eigene (verschiedene) CTT haben kann, muß das Spiel irgendwie mehrere CTTs verwalten können, und an der richtigen Stelle entscheiden, welche CTT gerade gültig ist, und dieser Gültigkeitscheck versagt hier.

Zitat: Die Anordnung der labels in der CTT hat übrigens keinen Einfluss auf das falsche Verhalten, damit habe ich gestern abend einige Zeit verbracht.

Aber versuch trotzdem spaßeshalber mal diese hier:

Eddi schrieb:[...]
Aber versuch trotzdem spaßeshalber mal diese hier:

Code:

[...]

// evtl. "Regearing"
// evtl. "Fish", "Waste" oder "Sugarcane"

Ich hatte es gestern schon mit einer CTT versucht die den in FIRS definierten cargo slots entspricht, ohne Erfolg. Ich hatte sogar ohne CTT versucht die entsprechenden bits zu setzen


auch ohne Erfolg. BTW, eine feste Zuordnung wäre auch nicht sinnvoll, die Verwendung einer CTT die die labels flexibel benutzen kann, wäre vorzuziehen.

Eddi schrieb:Das funktionierte also nur rein zufällig in dbxl_ecs, weil die Güter in der gleichen Reihenfolge standen.

Du meinst dass die CTT gar nichts bewirkt, weil nämlich (schon) die cargo bits 1:1 die ECS-cargo slots abbilden? Mag sein, aber dies lässt sich für FIRS irgendwie nicht erreichen. Ist also fraglich ob das so ist ...


Apropos: mir ist auch nicht klar welche Güter nun wirklich in FIRS enthalten sind. FISH jedenfalls, obwohl hier ständig und in der FIRS Doku angeführt, gibt es in der FIRS grf definitiv nicht.

Gruß
Michael

Ich glaube meine erste hier gepostete Liste war eine veraltete. Womöglich gibts aber auch noch Unterschiede zwischen 0.1.2 und Nightly...

Fish, Waste und Sugarcane, sowie Survey Supplies scheinen aber mittlerweile ausgeschieden zu sein.

Eddi schrieb:[...] Fish, Waste und Sugarcane, sowie Survey Supplies scheinen aber mittlerweile ausgeschieden zu sein.

Ja, ja. Die von mir eben geposteten bits/slots sind so in der Version enthalten mit der ich teste, allerdings ohne Erfolg.

Gruß
Michael

Ich habe 'mal in den FIRS-Sourcen etwas herumgewühlt. Es findet sich folgende Definition der Cargo-Bits bzw. IDs:

Die hier nicht (mehr) erwähnten Cargos werden meines Wissen nach auch (aktuell) nicht (mehr / vorübergehend) verwendet.

EDIT: nvm... das ist das, was Michael oben schon in Form von Cargo-Labels hat...

planetmaker schrieb:[...] EDIT: nvm... das ist das, was Michael oben schon in Form von Cargo-Labels hat...

Ja, und zwar aus der dekodierten und hier verwendeten FIRS grf. Die sollten also stimmen.

Gruß
Michael

(08.06.2010, 20:12)mb schrieb: [...] ohne Erfolg. [...]

Also ich hab das gerade mal hingehackt, das Ergebnis sieht dann so aus...

Mal abgesehen davon, daß die Mehrheitsregel für die "alles außer..." Auflistung etwas unschön ist, sieht das aber richtig aus...

Eddi schrieb:Also ich hab das gerade mal hingehackt, das Ergebnis sieht [...] richtig aus...

Könntest du bitte hier mal die entsprechende Bitmaske posten?

[edit]Bei mir wäre die, wie oben geschrieben, "1D c2 2f 1f 00"[/edit]

[edit2]
Hier mal eine neue Version zum testen:

  dbxl_firs.grf (Größe: 1,56 KB / Downloads: 296)
[/edit2]

Gruß
Michael

Also was ich mir gerade zusammengebastelt habe, sieht so aus:

• LOW: COAL / GRAI WOOD / IORE STEL SAND / FRVG / GRVL WDPR AORE / ALUM SCRP // Minus: FMSP
  0100 0011 1110 0100 1011 1100 0000 0000
  C2 27 3D 00
  
• TANK: OIL_ / MILK / WATR / PETR RFPR / FMSP // Plus: MILK, WATR, FMSP
  0001 0000 0000 1000 0100 0011 0010 0000
  08 10 C2 04
  
• BOX: MAIL / LVST GOOD / FOOD / MILK FRVG WOOL CTTN / FMSP ENSP MNSP SVSP // Plus: CTTN
  0010 1100 0001 1111 0000 0000 1111 0000
  34 F8 00 0F

(Reihenfolge in der CTT wie vorhin, Bitmaske mit LSB vorne, Abweichungen der Güter von deinem vorgeschlagenen Schema sind notiert)