Testphase und Diskussion zu "Add-Ons einreichen"

[Stefan (TheShow2006)]

Die Formulierung "andere Addons" habe ich so verstanden, dass die Dateien von anderen, nicht aber vom gerade von einem selbst eingereichten Addon verwendet werden könnten.
Prüft die Verwaltung nicht, ob das gerade einzureichende Addon die Dateien benötigt bzw. ist das so gewollt oder technisch nicht anders möglich?

Diese Tatsache ist mir auch schon aufgefallen. Wenn da einer nicht aufpasst, dann werden ggf. gemeinsame Komponenten und Sounds gelöscht obwohl andere Führerstände diese Dateien zwingend benötigen und der Bestand somit fehlerhaft wird.

Grüße

[Daniel R.]

Und nochmal zu Script:

Das Kommando "neuer Link" bedeutet laut Doku:

Lässt alle Dateien an den aktuellen Standorten und führt auch keine Umbenennungen durch. Aber alle Verknüpfungen „Alte Datei“ werden auf die „Neue Datei“ umgelenkt. Wenn ein Basispfad angegeben wird, wird nur innerhalb dieses Verzeichnisses gesucht.

In den Fahrzeugdateien der BR 215 und 218 habe ich ausschließlich die Verlinkung der neuen Führerstände geändert. Kann ich es mir also sparen, diese mit einzureichen, wenn im Script das Kommando "neuer Link" entsprechend verwendet wird?

[Carsten Hölscher]

Ich werde gelegentlich noch einbauen, dass die Verwaltung diese Frage automatisch prüft, bin bisher noch nicht dazu gekommen.
Kann man die ftd-Datei nicht nennen wie die alte? Dann ist das doch die einfachste Lösung.

Carsten

[Daniel R.]

Kann man die ftd-Datei nicht nennen wie die alte? Dann ist das doch die einfachste Lösung.

Das kann man machen. Während des Bastelns hatte ich es vorgezogen, im eigenen Datenbestand die alten ftd-Dateien nicht gleich durch die neuen zu überschreiben. Und es hatte sich bei den meisten Bastlern inkl. mir so eingebürgert, dass die neuen Führerstände im Dateinamen immer den Namenszusatz _HD oder _FullHD bekommen haben (z. B. um sie im eigenen Datenbestand vom Altbestand korrekt unterscheiden zu können).

Daniel

[MBT Kuhl]

Hallo,

bis vor zwei Jahren standen die Aufwandspunkte noch in den Exceltabellen drin, und zwar für jedes Objekt. Ich finde es sehr schade, dass das nicht mehr gegeben ist.

Die Standardbewertung mag für Standardhäuser gehen, aber die genauen Stunden kann man so nicht unbedingt abschätzen. Es gibt Objekte, die nur mit sehr hohem Aufwand zu vermessen sind, mühsame Farbabstimmungen bei ungünstigen Lichtverhältnissen, aber auch Loks mit 29 Stellungen des Fahrschalterhandrades, die alle ausgeschnitten werden müssen. Manche Dinge sind mal schnell improvisiert, andere extrem genau nachgebildet, was sich aber so nicht immer erkennen lässt. Ich verweise mal auf die Kartographie jedes einzelnen Schildes, Aschenbechers und Entwerters . Dann ist eine Angabe des Autors unerlässlich.

Als Alwin das ZPA noch gemacht hat, hat er bei Fahrzeugen die Daten für .rv.fzg recherchiert und eingetragen. Wer macht das jetzt? Ich kenne mich nicht perfekt damit aus, hätte aber eine recht relevante Lok fast veröffentlichungsreif. Wenn keine Einwände kommen, kopiere ich die .rv.fzg einer anderen Lok und ändere nur die Daten mit Bezug zu Geometrie, Gewicht, Leistung und Bremse.

Grüße
Moritz

[Traindrivertraxx]

Das würde ich bedauernswert finden. Gerade hinsichtlich der großen Detailtreue von technischen Daten ist Zusi eine Simulation und differenziert sich dadurch explizit von der Konkurrenz, welche eher Im Spiel und Spaß Segment agieren. Ich hoffe man findet hier eine geeignete Lösung, klar ist leicht gesagt, aber trotzdem wahr...

[Stefan (TheShow2006)]

bis vor zwei Jahren standen die Aufwandspunkte noch in den Exceltabellen drin, und zwar für jedes Objekt. Ich finde es sehr schade, dass das nicht mehr gegeben ist.

Spannender Einwurf. Da würde mich auch mal der Grund interessieren, denn die Transparenz ist dadurch nicht mehr gegeben.

Grüße

[Mario R.]

Nach meinen bisherigen fehlgeschlagenen Versuchen gebe ich es nun auf.
Nach dem aktuellen Prozedere, so meine Erfahrung jetzt, darf wirklich nichts im offiziellen Bestand verändert worden sein, da sonst der ganze Prozess nicht mehr funktioniert. Es reicht hier schon aus, wenn Dateien ein neueres Datum oder anderes Änderungsdatum haben, als der offizielle Zustand vorgibt.
Finde ich ehrlich gesagt eine etwas kurz gedachte und nicht ganz so smarte Lösung, denn wer einmal versehentlich im offiziellen Bestand etwas ändert kann nochmal Zusi3 neu installieren.
Wäre es hier nicht besser einen wirklichen Vergleich von Dateiinhalt Bastlerverzeichnis <-> Dateiinhalt offizieller Bestand für jede einzelne eingetragene Datei aus der Drag&Drop-Liste zu erstellen, da ich ja nicht alle anderen Files, sondern nur die ausgewählten Dateien veröffentlichen möchte?

Viele Grüße,
Mario

[F. Schn.]

Du kannst deinen Packversuch ja mal mir schicken, vielleicht kann ich ja helfen.

So ganz verstanden habe ich deinen Beitrag aber nicht. Das gilt jetzt auch allgemein: Ich sehe da viele Beiträge, wo mir einfach die nötigen Details fehlen und stattdessen böse Beschwerden über Alwins Abgang kommen. Ich habe auch nicht ganz verstanden, was jetzt deine Frage ist: Du möchtest im Zusi-Offiziell-Ordner, der durch Windows Schreibgeschützt ist, in dem Zusi nicht von alleine schreibt, und der nicht zum Ändern gedacht ist, etwas ändern? Und wie genau soll Zusi darauf dann reagieren, außer mit einer roten Warnmeldung ohne weitere Auswirkungen?

[Carsten Hölscher]

Wie schon geschrieben: Es scheint bei dir schon die xml-Datei des offiziellen Datenstands nicht (korrekt) zu existieren. Dann kann der Rest auch nichts Sinnvolles liefern. Ich hab mir die Doku extra noch einmal durchgelesen aber weiß auch nicht, was die offen lassen sollte. Also vielleicht schilderst Du mal im Detail, was Du machst, vielleicht werden wir dann schlauer.

Carsten

[Mario R.]

Ich lade die Datei für den offiziellen Datenbestand herunter, ziehe im Dateifenster die .ftd und die globale Fahrzeugdatei hinein und führe den Rest gemäß Doku durch. Mehr habe ich nicht gemacht und deshalb hat es mich auch sehr verwundert, dass ich was falsch gemacht hätte. Das einzige was ich mal getan habe, war aus Naivität im Juni letzten Jahres noch im offiziellen Bestand rumzuwerkeln... wer hätte da ahnen können, dass das an späterer Stelle nochmal zu Bruch führt.

Viele Grüße,
Mario

[Carsten Hölscher]

Das letzte jetzt sah ganz gut aus so auf den ersten Blick.

Carsten

[Juergen_Verheien]

Hallo Carsten,

habe die Module Hagen-Hbf und Rehsiepen für das Add-on nun fertig gestellt, geprüft und getestet, nach Doku und bestem Gewissen....

Wie gelangen die beiden nun zu Dir, ins SVN einchecken ?

[Carsten Hölscher]

Die entstandene zao-Datei muss zu mir, z.B. E-mail oder falls zu groß über irgendeinen Upload.

Carsten

[Michael_Poschmann]

Aktueller Befund beim Versuch, ein Modul zu exportieren:

- Im Bau-SVN sind zahlreiche Objekte noch in xml vorhanden, nicht in lsb-Version. Betrifft zum Beispiel die Catenary-Objekte.
- Modul also in ein eigenes Verzeichnis exportiert; dort die Dateien in lsb gewandelt.
- An einzelnen Dateien geprüft, sie sind bitgleich mit den offiziellen Dateien.
- Dennoch wird beim Addon-Erstellen der Marker "lokal geändert" gesetzt und die Datei mit exportiert.

Das Datumsfeld dürfte ja nicht ausgewertet werden. Wer eine Idee hat, wo der vermeintliche, das unerwünschte Verhalten hervorrufende "Unterschied" der Dateien liegen könnte, gerne her damit.

Grüße
Michael

[Carsten Hölscher]

Steht da "lokal geändert" (gelber Haken) oder im offiziellen Bestand geändert (rotes Warnzeichen)?

Carsten

[Michael_Poschmann]

Lokal geändert.

[Carsten Hölscher]

Kannst du mit die beiden Dateien mal schicken? Jeweils mit Angabe der Ablageverzeichnisse.

Carsten

[Michael_Poschmann]

Suche ich gleich raus.
Habe parallel noch weitere Stichproben durchgeführt. An einer Stelle sind in die offizielle Datei eigenartige Leerzeilen reingerutscht. Die werden natürlich zu einem "lokal geändert" führen.



Edith: es scheint auch unterschiedliche lsb zu geben. Ursache ebenfalls unklar.

Grüße
Michael

[Carsten Hölscher]

Ich möchte noch einmal die Defizite auflisten, was die eingereichten bei einigen Autoren angeht. Evtl. ist manches immer noch nicht so ganz klar.
- Es ist ausschließlich die Einreichenfunktion der Verwaltung zu benutzen (ich werde die in den nächsten Tagen noch erweitern). Wenn es Fragen gibt, bitte im Forum melden.
- Wenn dort Fehler gemeldet werden, dann sind die zu beachten und abzustellen! (hatte jetzt wirklich Fälle, wo dort fehlende Dateien bemängelt werden und es wird OK gedrückt und eingereicht...)
- Der Einreichen-Vorgang legt ja im Owndata-Verzeichnis das ausgelieferte Paket ab. Spätestens dort die Verknüpfungsprüfung der Verwaltung drüber laufen lassen (so lange das Datenverzeichnis auf dieses Exportverzeichnis setzen) - gemeldete Fehler abarbeiten!
- Es ist Sache des Autors eines Addon, auch die sinnvolle Einsortierung in die Datenstruktur zu betrachten. Also gibt es z.B. von einem Fahrzeug eine neue Variante, dann muss man sich anschauen, wo diese abgelegt wird, was das für Fahrzeugdatei und ggf. für die Fahrpläne bedeutet, welche alten Dateien überflüssig werden. Es muss am Ende eine sinnvolle Struktur entstehen, die wenn immer möglich die wichtigen Dateinamen beibehält (also z.B. Fahrzeugdateien, die ja in vielen Fahrplänen verknüpft sind). Ein Ansatz: "Sortier Dir meine Datenanlieferung halt hin wie Du meinst" kommt nicht in Frage. Der Autor eines Addons kennt sich am besten mit den Daten aus und ich kann mich nicht erstmal in jede Lokfamilie einarbeiten.
- Beim Einreichen-Prozess wenigsten ein paar Kommentare hinterlassen. Die Eingabefelder sind extra dafür da. Bitte nutzen. Wortlos angelieferte Daten machen mir das Leben hier schwerer

Die letzte Runde hat bei mir enorme Mengen Zeit verschlungen, die ich wirklich gerne anders investieren würde, das muss deutlich besser werden!

Carsten