[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