Testphase und Diskussion zu "Add-Ons einreichen"

[Alwin Meschede]

Bei Führerständen waren es die .dds.bmp, und bei Streckenmodulen habe ich jede st2 die ich in die Finger bekam an die Seite gelegt, damit man bei Bedarf ein Anschluss-Höhenprofil extrahiert kriegt. Blenderdateien habe ich nie haben gewollt.

[MarkusEgger]

Hallo!

Habe mich jetzt mal getraut und das Verwaltungsupdate eingespielt, damit ergibt sich aber wieteres Feedback:

- Auch bei mir wird (beim testweisen einreichen eines Fahrplans) alles aus dem RollingStock-Ordner als angeblich abweichend vom Originalbestand benannt, das ist aber definitiv nicht so. Da stimmt die Routine definitiv noch nicht. Dementsprechend rödelt die Verwaltung minutenlang rum weil es für jeden Zug einzeln die angeblich abweichenden RollingStock Dateien aufzählt (jedes Drehgestell, jede dds usw immer wieder...)
- Auch die Büsche, Bäume und vieles andere aus dem Terrain-ordner weicht angelich ebenfalls alles vom offiziellen Bestand ab, ist definitiv ebenfalls nicht der Fall..
- Alles was wir bisher gebaut haben wird als verändert gegenüber dem offiziellen Bestand gekennzeichnet. Ist auch logisch, denn bisher war es ja vorgegeben in der Mutter-ls3 die Aufwandspunkte reinzuschreiben. Bei der Veröffentlichung wurden die von Alwin entfernt, lokal bei uns stehen die aber immer drin, somit wird die Automatik immer jede jemals selbst gebaute Datei als verändert melden. Man müsste bei allen ls3-Dateien diese Einträge rausmachen, das kann aber wohl eher nicht ernsthaft gemeint sein. Somit wird man immer alle Dateien einreichen müssen. Werden dann zukünftig diese Einträge mitveröffentlicht? Sollte ja wohl eher nicht passieren. Wenn die dann wieder von Carsten rausgelöscht werden hat man aber jedes mal wieder Abweichungen vom veröffentlichten Zustand. Ist also noch etwas arg unausgegoren...
- Die Mutter ls3- eines Moduls wird nicht als "Basisdatei" aufgeführt, dementsprechend kann man für die keine Aufwandspunkte eintragen. Das werden unsere Landschaftsbauer nicht lustig finden. Bisher wurden Module so eingereicht, dass es für ls3 und st3 getrennte Aufwandspunkte und Autorennennungen gab. Zumindest in unserem Team ist es so dass es Leute gibt die nur entweder nicht an der st3 oder nicht an der ls3 beteiligt sind...
- Die Eintragung des Bauaufwands beim Einreichen des Moduls ist wenig praktisch. Da das ja einer aus dem Team für alle machen muss müsste der sich dann beim Moduleinreichen von jedem im Team die Zeitaufwände durchgeben lassen. Bisher hat jeder Objektbauer bei sich im Objekt den Aufwand in der ls3 eingetragen (s.o.), das war wensentlich praxisnäher. Absprechen mussten wir uns nur bei den echten Gemeinschaftswerken, im Mormalfall also nur der st3 und der ls3. Wie geht man beim Bauaufwand eintragen mit minimalen Korrekturen an den Dateien um? Bisher haben wir da nichts eingetragen.
- Nächste Preisfrage: Wie geht man zukünftig damit um wenn mehrere Autoren gemeinsam eine Datei erstellt haben? Wo kann man die Verteilung der Aufwandspunkte hinterlegen? Bisher war das möglich.

Markus

[F. Schn.]

Gleiche Frage wie bei Michael: Funktioniert bei dir der Knopf "Offizieller Datenbestand:" "Aktuelle Version herunterladen"? Wenn ja, warum geht er bei dir aber bei mir nicht?

[Michael Springer]

Wenn ich die Datei offiziell.script.xml händisch lösche und die Dateiverwaltung im Admin Modus starte, erhalte ich nach Drücken des Knopfes eine offiziell.script.xml vom 05.10.2019, die aber die 2 Seiten vorhergezeigten Inkonsistenzen zwischen meinem und dem "angeblich" offiziellen Datenbestand enthält.

Michael

[F. Schn.]

Also ohne Admin-Modus geht es bei dir auch nicht?

[Michael Springer]

Ich erhalte diese Fehlermeldung, was ich auch logisch finde, da ein Programm, dass mit Benutzerrechten läuft unter C:\Program Files (x86)\Zusi3\_ZusiData\_Setup\Downloads keine Schreibrechte hat.



Nachtrag:

Und als Text steht in der Verwaltung:
C:\Users\Public\Documents\Zusi_ALL\_Setup\Downloads\offiziell.script.xml.sqx
______________________________________________________________________________

[F. Schn.]

Allerdings wird die Datei ja gar nicht unter %ÖffentlichesDV%\_Setup\Downloads angelegt sondern unter %PrivatesDV%\_Setup\Downloads. Deswegen sollte es eigentlich klappen.

[Michael Springer]

Unter %PrivatesDV%\_Setup\Downloads landet bei mir keine Datei. Aber mit Adminrechten wird bei mir unter C:\Program Files (x86)\Zusi3\_ZusiData\_Setup\Downloads eine neue offiziell.script.xml 05.10.2019 04:49 angelegt. Ich vermute mal, dass die Datei nie physisch auf dem Laufwerk landet, sondern nach dem Herunterladen direkt im Speicher entpackt wird und in C:\Program Files (x86)\Zusi3\_ZusiData\_Setup\Downloads geschrieben wird, sofern Schreibrechte vorhanden sind.

Michael

[MarkusEgger]

Hallo!

Ich war so naiv und habe auf den Knopf gedrückt und mich drauf verlassen dass der was tut. Scheint aber nicht so zu sein.

Ohne Adminrechte schreibt er mir zwar hin:
C:\Users\*meinName*\Documents\Zusi3V1\_Setup\Downloads\offiziell.script.xml.sqx
ein Datei diesen Namens finde ich aber nicht.
Fehlermeldung habe ich keine.

Markus

[F. Schn.]

Okay, jetzt bin ich völlig verwirrt. Kann ich als erstes mal Carsten anfragen, ob du die Entsprechenden Themen hier und in viewtopic.php?p=299875#p299875" target="_blank mal in ein neues, drittes Thema im Fehlerforum auslagern könntest?

Generell ist es ein bisschen problematisch, wenn der Download Admin-Rechte benötigt, weil mit Admin-Rechten ist keinerlei Drag&Drop möglich und das ist eine Absichtliche Windows-Schutzmaßnahme. Ich wäre also dafür, dass es in den eigenen Daten landet:

Es müßte in den eigenen Daten landen.

Carsten

[Michael Skupin]

Hallo Leute

die Installation, wie von Markus Egger beschrieben, läuft bei mir genauso ab. Funktioniert naturgemäss nur mit Admin Rechten !

Die Datei landet, wie von M.Springer beschrieben, im Offiziellen Ordner, bei mir "C:\Program Files (x86)\Zusi3\_ZusiData\_Setup\Downloads".

Grüße
Michael

[Carsten Hölscher]

Das ist aber sehr seltsam, bei meinen Tests landet die korrekt in den eigenen Daten. Adminrechte sollten nicht nötig sein.

Hat jemand eine Idee, wieso Drag+Drop mit Adminrechten nicht geht?

Due Mutter-ls3-Datei des Moduls kann man einfach mit die Liste aufnehmen, siehe Dokuauszug. Bei 2 Autoren einfach 2x aufnehmen.
Die Aufwandszahlen sollen zukünftig aus den Dateien raus und separat organisiert werden, das ist jetzt eine Übergangsphase. Dazu in Kürze mehr.

Carsten

[F. Schn.]

Hat jemand eine Idee, wieso Drag+Drop mit Adminrechten nicht geht?

Weil der Windows Explorer ohne Admin-Rechte läuft und dadurch relativ unkontrolliert Daten an einen Prozess mit Adminrechten senden könnte.

[Michael Skupin]

...man hat auf "C:\Program Files (x86)\...." als normaler Anwender keine Schreibrechte, nur als Admin. Bei den andern Updates ist es ja genauso, das geht nur mit Admin rechten in der Dateiverwaltung...

[F. Schn.]

Ich kann es gerade nicht testen, aber ich erinnere mich an eine seltsame Begebenheit, landet die Datei eventuell in beiden Verzeichnissen?

Das man im Programme-Ordner keine Rechte hat ist klar, das ist ja überhaupt nicht die Frage.

[Michael Skupin]

die "offiziell.script.xml.sqx" Datei landet nirgendwo, zumindest habe ich die nicht gefunden

die "offiziell.script.xml" landet dann im Offiziellen Zusi Pfad "C:\Program Files (x86)\Zusi3\_ZusiData\_Setup\Downloads" und nicht im Bauverzeichnis oder eigenen Datenverzeichnis

[MarkusEgger]

Guten Morgen!

Zumindest für einen Teamorientierten Streckenbau bleibt diese Methode u.E. absolut suboptimal. Wir müssen zukünftig bei uns im Team einen "Einreichungsbeauftragten" ernennen, der erhebliche Zeit in das Zusammentragen von Informationen und in das Arbeiten für andere investieren darf. Stand gestern Abend war es so, dass sich eher niemand dazu berufen sieht seine rare Bastelzeit zukünftig der "spannenden" Aufgabe der Datenaufbereitung und des Einsammelns der Informationen bei den beteiligten Bastlern zu widmen. So funktioniert Teamarbeit nicht. Wir haben bisher unser Team so aufgestellt, dass jeder absolut selbst dafür verantwortlich war, dass seine Baubestandteile zu einem bestimmten Stichtag veröffentlichungsreif sind, unser QS hat dann durchaus diverse Checks durchgeführt, aber es hat nicht für die Beteiligten gearbeitet. Ich möchte die Mehraufwände und Nachteile an Hand eines möglichen Einreichens der fertigen Module Westendorf und Meitingen darstellen:

- Wir müssten jemanden finden, der sich darum kümmert vor der Veröffentlichung per Export aus der Verwaltung alle Module (auch die schon veröffentlichten, an jedem gab es bisher Optimierungen) und Fahrpläne in ein Exportverzeichnis zu exportieren und dort lsb's zu erzeugen.
- Jetzt könnte man tatsächlich nur die 3 Fahrpläne als einzureichen per Drag and Drop (wenns denn dann mal geht) auswählen, die Verwaltung würde alle notwendigen geänderten st3 und ls3 (also aller Module) und die neuen und veränderten Objekte identifizieren.
- Dann darf der arme Knilch stundenlang die Aufwandsstunden aus den einzelnen ausgewählten Objekten (das dürften dann je Modul immer mindestens eine zweistellige Zahl sein) auswählen und per Hand eintragen, diverse Anmerkungen und sonstwas in den Spalten verfassen - eine Sträflingsarbeit und dazu noch potentielle Fehler- und Ärgerquelle.

geschätzter Zeitaufwand für die Einreichung von Meitingen und Westendorf (inklusive der dafür nötigen teaminternen Kommunikation) mE etwa 10 Stunden, das ist ungefähr so das was ich in einer Woche im Bestfall in Zusi an Zeit investiere. Eine Spalte diese Aufwandsstunden für die Verwaltung einzutragen beim Einreichen gibts übrigens auch nicht

Zusammengefasst machen zwei Punkte erheblichen Zeitaufwand, den es bisher nicht gab:
- Generierung von lsb, die für uns keinerlei Nutzen haben
- Zentrale Einreichung


Formal besteht so eine Erweiterung einer Strecke um ein oder zwei Module eigentlich aus vielen kleinen neuen Addons: 3 Fahrpläne sind es bei uns, zwei neue und diverse überarbeitete Module mit st3 und ls3 und viele kleine neue oder überarbeitete Objekte (Häuser, Schilder, Signale usw). Durch das Hochbrechen der Aufwandspunkte aus dem Einzelobjekt (das für sich lebensfähig ist) in den Gesamtupload kann nicht mehr die Strategie verfolgt werden, dass jeder für sein Bauwerk selbstverantwortlich ist und dieses auch final selbst bearbeiten kann. Zum Einreichen einzelner Objekte oder Fahrzeuge ist die neue Methode sicherlich geeignet, zum veröffentlichen von in Teamarbeit entstandenen Zusi-Strecken ist sie absolut suboptimal.

Außerdem finde ich den Prozess wie hier die Lösung erreicht wird auch suboptimal. Es wird jetzt eine halb fertige Funktion veröffentlicht, in dem Zusammenhang wird dann auf noch eher beiläufig auf weitere kommende Änderungen hingewiesen (Herauslösung Aufwandspunkte aus ls3 und damit verbundene Notwendigkeiten), was noch mehr Unklarheiten schafft. Es wäre gut gewesen entweder vorher ein Konzept hier zu diskutieren, oder aber alternativ das ganze wneigstens fertig zu entwickeln. Jetzt diskutieren wir hier über eine halb fertige Lösung und kennen nicht nicht mal wirklich wie der Prozess dann später ablaufen soll. Wie soll denn später z.B. der Veröffentlichungsrhythmus sein? Gibt es wie bei Alwin im Regelfall einen monatlichen Stichtag bis zu dem eingeliefert wird und alles bis dahin eingelieferte (und korrekte) wird dann im Folgemonat veröffentlicht? Oder machen wir wieder die Zusi2-Lösung: Im Herbst wird ein Weihnachtspaket angekündigt, zudem es dann um Neujahr heißt dass es bald kommt und das dann irgendwann zwischen Ostern und Pfingsten erscheint? Das hat nämlich auch durchaus Einfluss darauf wie man sich als Team organisiert. Mit der bisherigen Lösung war es möglich kleine Fehlerkorrekturen innerhalb Minuten einzureichen und somit schnellstmöglich in den Veröffentlichungsprozess zu bringen, das klappt so auch nicht mehr.

Wie man den Sätzen schon entnehme kann sehe ich defintiv keine Vorteile für uns. Meine (und ich glaube nicht nur meine in unserem Team) Motivation da zusätzlichen Zeitaufwand zu versenken hält sich sehr in Grenzen, gerade weil Zusi-Basteln grade eh schon durch diverse "Dauerworkaraounds" eher anstrengend ist (ich erinnere an die davonschwebenden DEMs, die voreilige st3-Datenversion-Migration nach A.2 usw.)

[MarkusEgger]

Nachtrag um noch was konstruktives beizutragen:

Wäre es nicht eine Idee die Themen wie Aufwandspunkte etc. in eine separate Textdatei (ähnlich der Autordatei) zu packen, die dann eingereicht aber nicht veröffentlicht wird? Damit wäre zumindest jedes Teil-Addon (Objekt usw) für sich lebensfähig und die Sammeleinreichung würde nur draus bestehen für die Streckenmodule die abhängigen Teiladdons zu ermitteln und mithochzuladen. Aber die Struktur dass ein Autor für ein Objekt verantwortlich ist würde bestehen bleiben.

Markus

[Carsten Hölscher]

Die externe Aufwandsdatei kommt wie gesagt. Es soll nun aber auch mal das Paket 102 an den Start - das ist im Moment halt ein Kompromiss aus Funktion noch nicht final schön und anstehende Add-Ons mal endlich veröffentlichen. Wär Alwins Dienstende hier mit Vorankündigung gekommen, wäre das eleganter gegangen.

Zum Rest: Wie soll es denn sonst laufen? Ich hab keine Verbesserungsvorschläge entnommen.

Carsten

[Carsten Hölscher]

Allerdings wird die Datei ja gar nicht unter %ÖffentlichesDV%\_Setup\Downloads angelegt sondern unter %PrivatesDV%\_Setup\Downloads. Deswegen sollte es eigentlich klappen.

Kannst Du bitte jetzt mal probieren und schauen, wo die Datei landet? Am Server ist was geändert. Ich bau sonst mal ein genaueres Logging in die Verwaltung.

Carsten