[Graphic Ressource Management]

Bernhard schrieb:http://wiki.ttdpatch.net/tiki-index.php?...Management

Ganz kurz auf deutsch (ich hoffe richtig): GRFs können selber bestimmen, mit welchen GRFs zusammen sie im Spiel laufen wollen. Also Kann z. B. dem DBSet mitgegeben werden, dass es weder mit dem USSet, noch dem canSet läuft, bzw. gar keine anderen LOKs neben sich duldet. [...]
Alternativ kann sich natürlich auch ein Set, wenn es feststellt dass es mit anderen kollidiert, sich selber abschalten (gelbes Kästchen im Menü).

Das ist aber nicht GRM, sondern das ganz normale übliche Verhalten einer .grf, so wie es bereits seit ewigen Zeiten bekannt ist. D.h. wenn eine .grf erkennt dass eine bestimmte andere .grf bereits aktiv ist oder aktiviert werden wird, kann sie sich selber de-aktivieren, d.h. "abschalten" (oder auch nicht).

GRM hingegen ist eine Ressourcenverwaltung, die auf Basis von IDs arbeitet (zB Fz-IDs, TTD-Sprites, Güterarten, "general IDs"). Hier ist es so dass eine .grf prüfen kann ob ein bestimmter Block, zB von Fz-IDs zur Verfügung steht und ihn dann (gegebenenfalls) exklusiv reservieren kann. Es ist also nicht erforderlich, zu prüfen welche anderen .grfs bereits aktiv sind, oder noch aktiviert werden würden. Auch ist nicht erforderlich zu wissen welche ihrer IDs gegebenenfalls "kollidieren" würden.

Konkret: Im Fall von GRM würde der DB Set zB die Fz-IDs 00 - 47, sowie 4B - 73 reservieren. Welche anderen Sets noch im Spiel sind (USSet, CanSet, ...) wäre aber völlig egal.

Fazit: Gerade bei dem mittlerweile vorliegenden Problem viel zu vieler (unbekannter) .grfs wäre GRM das Mittel der Wahl. Und genau dafür wurde es auch entwickelt.

Gruß
Michael

dann kann sich also kein anderes Set die reservierten Resurcen crallen und schon kommpt es zu weniger Komplikationen, ist das so richtig?

Paltinium schrieb:dann kann sich also kein anderes Set die reservierten Resurcen crallen und schon kommpt es zu weniger Komplikationen, ist das so richtig?

Genau. So etwa wie ein Betriebssystem den Speicher für verschiedene Programme verwaltet.

Gruß
Michael

wäre gut wen es das auch bei openttd gibt. dan bräuchte der programmierer *räusper* sich nicht so viele gedanken machen

In der Tat stellt die Implementierung von GRM einen nicht trivialen Mehraufwand dar. Darum scheuen es die Programmierer und es konnte sich nicht durchsetzen. Hätte man das zusammen mit einer Abstrahierung des NFO-Codes in Angriff genommen, wäre es vielleicht keine Totgeburt geworden.

RK schrieb:In der Tat stellt die Implementierung von GRM einen nicht trivialen Mehraufwand dar. Darum scheuen es die Programmierer und es konnte sich nicht durchsetzen. Hätte man das zusammen mit einer Abstrahierung des NFO-Codes in Angriff genommen, wäre es vielleicht keine Totgeburt geworden.

Meinst du jetzt die OTTD-Programmierer oder die .grf-Programmierer? Für letztere ist es doch ganz einfach GRM-Funktionalität einzubauen. Trotzdem tut es keiner.

Gruß
Michael

*Salz in die Wunde streuend*

ich weiß ja nicht was RK mit "Abstrahierung des NFO-Codes " meint, ich hätte es schön gefunden, wenn man die GRF-Codierung so vereinfacht hätte, das es mehr Menschen verstehen! Ich kann mir einfach nicht vorstellen, dass das alles so kompliziert sein muss!

Beispiel:

multihead = 1
speed = 250
power = 100
weight = 300
loading = 80
lokpic = 1-4
wagenpic = 5-9

Bernhard schrieb:*Salz in die Wunde streuend*

ich weiß ja nicht was RK mit "Abstrahierung des NFO-Codes " meint, ich hätte es schön gefunden, wenn man die GRF-Codierung so vereinfacht hätte, das es mehr Menschen verstehen! Ich kann mir einfach nicht vorstellen, dass das alles so kompliziert sein muss! [...]

Doch, es ist kompliziert (die .nfo Repräsentation muss klein und kompakt genug sein um direkt in den ausführbaren Code übernommen zu werden, und ein "Compiler" auf Hochsprachebene für .nfo ist aus vielen Gründen (zB selbstverändernder Code) nicht einfach). Wenn dich das Thema tatsächlich interessieren sollte bin ich gerne bereit dir die einschlägigen Diskussionen auf tt-forums dazu herauszusuchen.

Gruß
Michael

Das Thema interessiert mich, aber ich habe leider nicht die Zeit mich darin zu vertiefen.
Job, Familie... ist wichtiger.
ich werde irgendwann mal meine grfs überarbeiten, aber für anderes hab ich (vor der Rente) leider keine Zeit

Trotzdem Danke für Dein Angebot.

naja laut deinen bild bist du ja bald in rente

Um wieder auf das OP zurückzukommen, ich habe nun mal alle möglichen verschiedenen Versionen auf meinem Rechner und dem USB-Stick gelöscht. Auch danach war keine Änderung in den verfügbaren Fahrzeugen zu sehen.

Nachfolgend habe ich alle Grafikdateien gelöscht und neu installiert. Und hier bin ich dann fündig geworden. Sobald die Datei "NewCargo Set V0.12 14.09.05" geladen wird, fängt das DB Set das spinnen an und erzeugt den von mir beschrieben Fehler ab dem Jahr 1926.

Wie kann man dem nun abhelfen?

Gruß Jens

verbundinfo schrieb:[...] Sobald die Datei "NewCargo Set V0.12 14.09.05" geladen wird, fängt das DB Set das spinnen an und erzeugt den von mir beschrieben Fehler ab dem Jahr 1926.

Wie kann man dem nun abhelfen?

Am einfachsten indem du das NewCargo Set aus der .grf-Liste entfernst.

Gruß
Michael

(29.11.2008 12:05)mb schrieb:  

verbundinfo schrieb:[...] Sobald die Datei "NewCargo Set V0.12 14.09.05" geladen wird, fängt das DB Set das spinnen an und erzeugt den von mir beschrieben Fehler ab dem Jahr 1926.

Wie kann man dem nun abhelfen?

Am einfachsten indem du das NewCargo Set aus der .grf-Liste entfernst.

Dann ist aber auch nichts mehr mit Fisch und Konsorten zu transportieren?

Grüßle

(29.11.2008 12:18)verbundinfo schrieb:  

(29.11.2008 12:05)mb schrieb:  

verbundinfo schrieb:[...] Sobald die Datei "NewCargo Set V0.12 14.09.05" geladen wird, fängt das DB Set das spinnen an und erzeugt den von mir beschrieben Fehler ab dem Jahr 1926.

Wie kann man dem nun abhelfen?

Am einfachsten indem du das NewCargo Set aus der .grf-Liste entfernst.

Dann ist aber auch nichts mehr mit Fisch und Konsorten zu transportieren?

Nein.

Aber ich verstehe das Problem nicht ganz. Aus deiner geposteten .grf-Liste entnehme ich dass du den NewCargo Set nach dem DB Set lädtst, was auch richtig ist.

Der NewCargo Set enthält lediglich Code der die im DBSet enthaltenen geschlossenen Gü-wagen modifiziert, d.h.:

- den kurzen geschlossener Wagen (1F)
- den normalen geschlossener Wagen (20)
- die 2 Kühlwagen (2E und 40)

Nur die Frachtmasken (prop 1D) werden verändert. Es wird ansonsten nichts angetastet. Es werden auch keine "neuen Wagen" erzeugt.

Wo die von dir bemängelten beiden Gü-Wagen herkommen, ist dadurch aber noch lange nicht zu verstehen.

Ich kann das im Moment nur unter TTDPatch testen. Aber auch unter OTTD scheint das Problem noch niemand sonst bemerkt zu haben (?). Der Set is immerhin von 2005 ...

Frage: benutzt du dieses "multitool-Feature"?

Gruß
Michael

(29.11.2008 12:30)mb schrieb:  

(29.11.2008 12:18)verbundinfo schrieb:  

(29.11.2008 12:05)mb schrieb:  [quote='verbundinfo']

Am einfachsten indem du das NewCargo Set aus der .grf-Liste entfernst.

Dann ist aber auch nichts mehr mit Fisch und Konsorten zu transportieren?

Nein.

Dann könnte ich also bequem das New Cargo Set weglassen?

(29.11.2008 12:30)mb schrieb:  Aber ich verstehe das Problem nicht ganz. Aus deiner geposteten .grf-Liste entnehme ich dass du den NewCargo Set nach dem DB Set lädtst, was auch richtig ist.

Der NewCargo Set enthält lediglich Code der die im DBSet enthaltenen geschlossenen Gü-wagen modifiziert, d.h.:
- den kurzen geschlossener Wagen (1F)
- den normalen geschlossener Wagen (20)
- die 2 Kühlwagen (2E und 40)
Nur die Frachtmasken (prop 1D) werden verändert. Es wird ansonsten nichts angetastet. Es werden auch keine "neuen Wagen" erzeugt.

Wo die von dir bemängelten beiden Gü-Wagen herkommen, ist dadurch aber noch lange nicht zu verstehen.

Ich habe die verschiedensten Sets zum DB Set geladen, auch diese ECS, erst als ich das NewCargo Set mit reingenommen habe, tauchen diese beiden Wagen wieder auf!

(29.11.2008 12:30)mb schrieb:  Ich kann das im Moment nur unter TTDPatch testen. Aber auch unter OTTD scheint das Problem noch niemand sonst bemerkt zu haben (?). Der Set is immerhin von 2005 ...

(29.11.2008 12:30)mb schrieb:  Frage: benutzt du dieses "multitool-Feature"?

Nein! Behaupte ich jetzt mal spontan. Nie was davon gehört.

Gruß Jens

verbundinfo schrieb:Dann könnte ich also bequem das New Cargo Set weglassen?

Das NewCargo Set definiert die beiden Güter "Fisch" und "Bier", sowie die beiden neue Industrien "Foschgründe" und "Brauerei", und modifiziert die Frachmasken der angegebenen DB Set Güterwagen. Ausserdem werden noch einige der originalen TTD-Gebäude so verändert dass sie Fisch oder Bier annehmen können.

Neue Wagen werden nirgendwo definiert. Ich gehe auch jede Wette ein dass sich die Modifikation der Frachtmasken im NewCargo Set nicht derartig auswirken kann dass das von dir beschriebene Problem ergibt. Ich höre davon übrigens auch zum ersten Mal. Ist also schon recht mysteriös, die Sache.

Zitat:Ich habe die verschiedensten Sets zum DB Set geladen, auch diese ECS, erst als ich das NewCargo Set mit reingenommen habe, tauchen diese beiden Wagen wieder auf!

ECS-"Vektoren" und NewCargo Set sind inkompatibel.

Zitat:["multitool-Feature"]
Nein! Behaupte ich jetzt mal spontan. Nie was davon gehört.

Schau einmal nach ob du es aus Versehen eingeschaltet hast.

Noch mal: einen anderen Fahrzeugsatz (für Züge) neben dem DB Set benutzt du nicht gleichzeitig?

Gruß
Michael

Multi-Pool gibt's nur im Trunk!
Da kann man mehrere Sets zusammenstellen.
Also z.B. Deutsche Lok & Canadische Personenabteile.