Add-On-Handhabung

Nachdem sich früher ein erhebliches Chaos auf dem Add-On-Sektor ergeben hatte, wurde es notwendig, die Add-Ons zentral zu verwalten, damit sich bei allen Nutzern ein einheitlicher Datenbestand herstellen läßt.

Es haben sich ein paar Leute bereit erklärt, die Prüfung neu erstellter Add-Ons durchzuführen, um so sicherzustellen, dass keine unsinnigen Daten und und chaotische Verzeichnisstrukturen bei den Nutzern entstehen. Durch diese Prüfinstanz ist ein einheitlicher Datenstand für alle Nutzer möglich, womit Zusi trotz der bei großen Strecken riesigen Zahl benötigter Dateien immer ohne Probleme laufen sollte. Federführend kümmert sich Stefan Hums ("Zusi-Prüfamt - ZPA") um diese Prüfarbeit, unterstützt wird er von den auf seiner Seite aufgeführten Personen.

Um im Zweifelsfall ein klare Regelung zu haben, wurden mit breiter Zustimmung der Bastler folgende Verhaltensrichtlinien erstellt, die den Umgang mit den Add-Ons gegenüber Nutzern und Erstellern regeln:

Zum Inhalt der Prüfungen gibt es hier eine kleine Checkliste typischer Fehler/Probleme. Ausführlichere Infos dazu bei Stefan Hums. Wer Add-Ons einreicht, möge diese Liste bitte vorher durchgehen, um den Prüfern das Leben nicht unnötig schwer zu machen:

Allgemein

• Die Dateien müssen in die aktuelle Dateistruktur passen
• Die Dateienamen sind eindeutig zu wählen und nach Möglichkeit ist beim Ersetzen vorhandener Dateien die alte Namensgebung beizubehalten (falls sie nicht komplett falsch oder mehrdeutig ist)
• Keine Umlaute und andere Sonderzeichen im Dateinamen (da es beim Packen damit immer wieder Probleme gibt)

Führerstände (*.fst)

• Die Bilder müssen hochwertig sein, also nicht unscharf oder schlecht retuschiert. Die Skalen und Melder müssen im Rahmen des Machbaren lesbar sein.
• Melder müssen genau soviele Bitmaps besitzen, wie sie brauchen, nicht mehr und nicht weniger
• Alle Bitmaps müssen bei 1024x768 unskaliert dargestellt werden. (die zu einem Instrument gehörenden Bitmaps haben also logischerweise alle gleiche Abmessungen)
• Bitmaps müssen fehlerfrei dargestellt werden. (z.B. keine Ränder an den transparenten Übergängen, keine Fehlpixel usw.)
• Instrumente müssen korrekt skaliert sein, (Abweichung sollte z.B. bei Tachos nur in niedrigen einstelligen km/h-Bereichen auftauchen)
• Die Zeigerträgheit unter 2.4 sollte einigermaßen authentisch sein (Zugkraftmesser sind z.B. recht träge, Manometer eher schnell)
• Zeigertexturen müssen passen, also richtig ausgerichtet und auch in bei Nachtfahrt zu sehen sein
• Hebel müssen nachts mit abgedunkelt werden
• Nach Möglichkeit sollte die Instrumentenbeleuchtung nach "Modus 11" ausgeführt sein (Näheres im Forum)
• Das Sichtfenster nach vorne muss vollständig nutzbar sein (Für 2.3 gilt natürlich die bekannte Ausnahme mit dem Vorhang im Fenster, wenn Instrumente überlappen)
• Es dürfen keine unnötigen (kostet Rechenleistung) und keine fehlenden (falsche Darstellung) Überdeckungen eingetragen sein
• Die Hebel müssen perspektivisch und optisch zum Führerstand passen. Nach Möglichkeit sind fotografierte Hebel zu benutzen
• Die Dateistruktur muß der Nomenklatur nach Standard des Führerstandseditor-Bitmap-Editors folgen.
• Versionen 2.3 und 2.4 müssen beide vorhanden sein

Fahrzeuge (*.lok, *.wag)

• Die Länge muß zur ls-Datei passen (keine Längenzugabe)
• Es ist eine von unten angebrachte Deckplatte vorzusehen. Diese ist notwendig, weil sonst bei unterschiedlich hoch verlegten Gleisen eine freie Sicht von unten durch den Wagen hindurch entsteht. Es geht hier aber nur um Wagen, die auch im Vorbild die freie Durchsicht verwehren.
• Pufferhöhe zwischen 940 und 1065mm
• Es werden nur Fahrzeuge in den offiziellen Datenbestand übernommen, die ein konkretes Vorbild besitzen, und diesem hinsichtlich ihrer Abmaße, Lackierung und technischen Daten auch entsprechen.
• Insbesondere folgende Werte sollten gemäß Vorbild ermittelt, notfalls plausibel geschätzt werden:

1. LüP
2. Bremsgewichte, Masse, Höchstgeschwindigkeit (Falls es verschiedene Höchstgeschwindigkeiten mit den selben Bremsmassen gibt, muss auf jeden Fall immer die höhere Geschwindigkeit eingetragen werden, eine zweite Version zu vermeiden)
3. Bremsbauart, Masse leer/beladen, Geschwindigkeiten leer/beladen und Bremsgewichte leer/beladen (bei nicht vorhandenen Bremsstellungen ist das Bremsgewicht 0 t)
4. Achsabstand bzw Drehzapfenabstand (muß nicht unbedingt auf den mm stimmen das nicht alles auf den mm stimmen, die Größenordnung sollte aber schon in etwa hinkommen. Auch um einen stimmigen Gesamteindruck zu anderen Fahrzeugen zu erhalten.)
5. Drehgestellbauarten

• PZB-System und Einstellung, Bremsventilbauart, Fahrschalter und AFB muß zu den Anzeigen und Instrumenten im zugeordneten Führerstand passen (Vorhandensein der Anzeigen und passender Anzahl der Schalterstellungen)
• Der Blickwinkel muß zum Führerstand passen, so daß die Fluchtpunkte im Führerstand und in der Streckensicht in demselben Punkt liegen
• Die Variantenvielfalt ist zu begrenzen auf die Typen, die im Zusi unterscheidbar sind und sich nicht zu sehr ähnlich sind. z.B. braucht es keinen eigenen Wagentyp mit derselben Ls-Datei, der geringfügig mehr wiegt, ansonsten aber identisch ist
• Dateinamen bei den Güterwagen (im Einzelfall können natürklich weitere Benennungen notwendig werden)

1. Jeder Wagen bekommt den Eigentümer bzw. Einsteller vorangestellt. Danach folgt die genaue Bezeichnung des Wagens mit Gattung und Bauartnummer. Danach folgt die Farbe. Ein Beispiel: DB_Snps719_vr
2. Bei Wagen, bei denen das Ladegut sichtbar ist und demzufolge auch verschiedenes Ladegut dargestellt werden kann, wird es auch konkret im Dateinamen mit auftauchen (z.B. DB_Snps719_Holz.wag)
3. Leere Wagen erhalten keinen Zusatz, der Grundzustand der Wagen ist unbeladen
4. Wagen, deren Ladegut nicht sichtbar ist, erhalten für den beladenen Zustand den Zusatz beladen
5. Wagen, die eine Handbremse, den meisten besser bekannt als Bremserbühne, besitzen, erhalten nach ihrer Gattungsbezeichnung ein kleines b.
6. Existieren mehrere Farbvarianten von einer Lackierungsvariante (z.B. verschiedene Brauntöne), so sind sie als V1, V2, V3 usw. gekennzeichnet.
7. Existieren im Vorbild Unterbauarten, die durch eine zusätzliche Zahl an der Bauartnummer gekennzeichnet sind (z.B. Eanos-x052 und Eanos-x052.1), so wird im Dateinamen ein "-1" ergänzt (Eanos-x052-1)

Landschaft (*.ls)

• Die Anzahl der Dreiecke muß sich im akzeptablen Rahmen bewegen. Als Richtwert für Fahrzeuge können maximal 1000-1500 pro Lok, 800 für aufwendige Wagen bzw. für aufwendige Ladegüter angesehen werden. In ihrer Darstellung nicht so aufwendige Wagen sollten deutlich unter 800 Dreiecke besitzen. (Einzelwerke können schon mal etwas drüber liegen, kommt auch auf den Charakter des Fahrzeugs an. Eine Dampflok z.B. wird mit 1000 Dreiecken kaum vernünftig hinzukriegen sein)
• Bei Fahrzeugen müssen Schluß- und Frontlampen mit den entsprechenden Polygontypen eingerichtet werden
• Bei Fahrzeugen, Signalen usw. sind die Zusi-üblichen Farbtöne zu verwenden
• Eine sehr starke Zergliederung in viele kleine, verknüpfte Dateien ist zu vermeiden (Performanceprobleme)

Strecken (*.str)

• Eine umfassende Funktionsprüfung ist hier nicht möglich, es wird empfohlen, vorab Beta-Versionen testen zu lassen (vorzugsweise im Forum finden sich immer Tester)
• Es dürfen keine Objekte aus anderen Strecken-Verzeichnissen benutzt werden, da alle Strecken unabhängig sein sollen (war früher anders und gab Chaos...)
• Die Routine für nicht benötigte Signalbegriffe muß durchlaufen worden sein, auch die anderen "Abschließenden Arbeiten - ganz am Ende" werden gerade für große Strecken empfohlen
• Beim Fahrtende am freien Streckenende soll die Fahrt entweder vor einem regulär angekündigten Haltsignal oder völlig überraschend durch das Ereignis "Zug entfernen" beendet werden, nicht jedoch durch überraschend auftauchende Haltsignale
• Die Fahrpläne müssen durchlaufen
• Brems- und Indusi-Einstellungen müssen plausibel sein, siehe Dokumentation->Vorschriften