Zusi-Forum

Hallo,

Christian Gründler hat geschrieben:

Außerdem ist darauf zu achten, dass sich Hüllkurven von benachbarten Modulen nicht überlappen (auch in den Randbereichen).

Für mein Gefühl sollte das "(auch nicht in den Randbereichen)" lauten.

M.f.G. Christian

oder so lesen: Außerdem ist darauf zu achten, dass sich Hüllkurven von benachbarten Modulen nicht überlappen ([bitte] auch in den Randbereichen [darauf achten]).


LG Conny

^^ Gut, ich werde das noch so umformulieren, dass man kein Germanistikstudium dafür braucht.

Vielleicht noch etwas Hintergrund, warum ich so auf den Randbereichen herumreite: Das ging auf einen Zufallsfund zurück. So verquer denkt man normalerweise gar nicht. An zwei Stellen war das betroffene Team selber über ihre eigenen Hüllkurven gestolpert. Die überlappten nämlich und ragten gegenseitig in die Nachbarmodule ein. Anstatt zu dem Schluss zu kommen "okay, die Hüllkurven sind nicht sinnvoll gezogen worden und sollten geändert werden", wurden die überlappenden Grasdreiecke im sichtbaren Bereich der Strecke von Hand gelöscht. Zum Rand hin (mehrere hundert Meter von der Bahnachse entfernt) sagte man sich wohl "ich hab keine Lust mehr, den Rest der Überlappung lasse ich stehen, das merkt sowieso keiner". Das hätte wohl auch wirklich keiner gemerkt, wenn es nicht genau an der Stelle ein noch im Bau befindliches Nachbarmodul gegeben hätte, mit dem man bei einem Testimport diese ganzen Einragungen und Überlappungen plötzlich gut sehen konnte.
Das Problem mit den Überlappungen stellt sich übrigens von vornherein nicht, wenn die Hüllkurven von Nachbarmodulen so aneinander angepasst werden, wie es in der Doku beschrieben ist.

Christian Gründler hat geschrieben:
P.S. Die Spanier verwenden übrigens für "auch" und "auch nicht" zwei verschiedene Worte ("también" bzw. "tampoco"), und hier liegt eindeutig der zweite Fall vor.

Die Spanier bezeichnen die Ehefrau auch als "la esposa" während "las esposas", also die Mehrzahl sowohl für die Ehefrauen als auch für die Handschellen verwendet wird.

Christian Marx hat geschrieben:

Christian Gründler hat geschrieben:
P.S. Die Spanier verwenden übrigens für "auch" und "auch nicht" zwei verschiedene Worte ("también" bzw. "tampoco"), und hier liegt eindeutig der zweite Fall vor.

Die Spanier bezeichnen die Ehefrau auch als "la esposa" während "las esposas", also die Mehrzahl sowohl für die Ehefrauen als auch für die Handschellen verwendet wird.

Womit ja wieder der Zusammenhang zwischen Eheschliessung/Verurteilung, Standesbeamten/Richter hergestellt ist Zum Glück gerade 4 Wochen Strohwitwer

Aus einem aktuellen Anlass heraus möchte ich einmal erläutern, unter welchen Bedingungen die Addons eines anderen Autors durch neue Addons aus dem Bestand rausgekegelt werden können.

Alter und neuer Autor sind sich einig
"Hier ist ein neues Addon als Ersatz für XYZ. Ich habe das mit dem Altautor besprochen, und er findet das gut". Dies ist der Idealzustand. Macht für mich als ZPA auch am wenigsten Arbeit.

Alter und neuer Autor haben vorher nicht miteinander gesprochen
In diesem Fall muss das neue Addon eine signifikante Verbesserung gegenüber dem alten Zustand darstellen. Dieser Nachweis ist oft formlos und unstrittig möglich. Zum Beispiel wenn ein Zusi-2-Altführerstand durch einen handwerklich gut gemachten HD-Führerstand ersetzt werden soll.
Was wir unbedingt vermeiden wollen, ist dass Autoren einander frustrieren, indem sie sich gegenseitig ihre Addons aus dem Bestand rauskegeln, weil Dinge nur um des Neubaus willen neu gebaut werden, oder wegen Kleinkram-Verbesserungen.
Es gibt Fälle, wo der Nachweis einer signifikanten Verbesserung schwer zu führen ist, oder auch sehr subjektiv ist. Bei Sound ist das öfter so. In dem Fall hilft es allen Beteiligten, wenn der neue Autor vorab 10 Minuten investiert, um hier im Forum einmal aufzuschreiben wo er Schwachpunkte des Bestands-Addons sieht. Dann kann man gemeinsam darüber entscheiden, ob ein Komplettneubau sinnvoll ist, oder ob Änderungen am Bestandsteil vielleicht doch der bessere Weg wären.

Alwin gehts in dem konkreten Fall nun um ein Fahrzeug oder wie?

Beim aktuell anstehenden Paket 25 haben wir erstmals den Effekt, dass Dateinamen inkl. Pfad zu lang sind. Ich hab jetzt einen Grenzwert von 170 Zeichen definiert. So bleiben also noch 85 Zeichen für das Datenverzeichnis, was mit allen üblichen Installationen harmonieren sollte.
Alle künftigen Programmversionen werden beim Speichern eine Warnung ausspucken, wenn der Wert überschritten wird. Verwaltungsprüfung checkt das dann auch ab.

Carsten

Wie steht eigentlich das ZPA zur Funktion 3D-Editor -> Finale Optimierung -> Nicht erreichbare Elemente löschen?
Die Suchfunktion spuckt weder in der Zusi-Doku noch in den ZPA-Richtlinien zu "finale" etwas aus.
Ich habe daher mal in Obernjesa geschaut, dort hat das ZPA offenbar die Ausführung der Funktion für Überflüssig erachtet. Kann man die Funktion daher einfach weglassen?

Ich halte nicht viel von solchen nicht reversiblen Optimierungen. Man sollte an der Stelle schon etwas weiter denken als nur von 12 bis Mittag, und sich vielleicht an die Zusi-2-Zeit erinnern. Dort konnte nur der Originalautor selber seine Strecke nachträglich vergrößern oder wesentlich umbauen. Dass das heute nicht mehr so ist, ist eine Errungenschaft die meiner Meinung nach unterschätzt wird. Also man kann sich mit Funktionen wie "Nicht erreichbare Elemente löschen" oder "Meshsubsets zusammenführen" schwer in den Fuß schießen und nachträgliche Verbesserungen am Streckenmodul unmöglich machen. Deshalb ist meine Empfehlung: Lasst die Finger davon.

Sehe ich ähnlich, insbesondere falls dereinst mal das Thema Rangieren auf die Tagesordnung gerät.

Grüße
Michael

Ich sehe es anders... Beispiel Herbertshofen, darauf zielte die Frage ab... Muss ich wirklich 4000 Straßenvektoren aufheben, wenn ich nur 1000 Gleisvektoren habe?



Wir sprechen von 1500kb zu 648kb. Wenn ich mir dann einen Fahrplan ansehe, wo Zusi 40 Module parsen muss... bei 6 Sekunden pro Modul sprechen wir von 4 Minuten mehr Ladezeit... bei jedem Test, bei jedem Spieler, usw. Man kann die Straßen-Vektoren aus dem SVN mit Copy und Paste wieder einbauen, wenn es gebraucht wird.

Michael

Nein, Straßenvektoren kann man sicherlich raushauen, das halte ich ebenso.
Wobei ein Backup *mit* Vektoren sinnvollerweise natürlich aufgehoben werden sollte für den Fall der Fälle. Versionsmanagement macht das aber leicht möglich.

Grüße
Michael

Moin,

also die Funktion "Meshsubsets zusammenführen" würde ich schon manchmal gerne benutzen, aber leider funktioniert sie nur nach dem Motto "alles oder nichts".
Wünschenswert wäre, dass man 2 oder mehrere Subsets markiert, und die dann zusammengeführt werden, falls es technisch möglich ist.

Wenn es sowas schon gibt, wäre ich froh, es zu erfahren; es gibt so viele Funktionen, die man nicht auf Anhieb findet.

Gruß
Hans-Peter

Es geht im vorliegenden Fall explizit um zwischenzeitlich sogar lauffähigen Straßenverkehr.

Nochmal Thema "Meshsubsets zusammenführen". Ich hätte jetzt Bedarf an einer Grundsatzentscheidung zum Thema "jonglieren mit optimierten und nicht-optimierten Streckenmodulen". Wir haben erstmals einen Autor, der sagt "ich will zur Veröffentlichung ein Streckenmodul einreichen, das mit 'Meshsubsets zusammenführen' behandelt wurde und dadurch 6 fps schneller läuft". Die unoptimierte Version will der Autor ausschließlich bei sich lagern (nebenbei gesagt wäre ich als ZPA aber sowieso vom Ablauf her nicht in der Lage, optimierte und unoptimierte Version im ZPA-Bestand parallel vorzuhalten, ohne dass es früher oder später zu versehentlichen Vertauschungen kommt).

Ich bin da ziemlich skeptisch, ob man diesen Ansatz überhaupt zulassen sollte. Neben dem bekannten Problem, dass der Zusi-Community nur noch die schwer änderbare optimierte Version zur Verfügung steht, wenn ein Autor mal endgültig abtauchen sollte, befürchte ich auch erhebliche Schwierigkeiten bei der ZPA-Arbeit. Wenn zum Beispiel so wie letztens ein paar unmaßstäbliche Fahrleitungsmasten auszutauschen wären, dann konnte ich das bislang in Ruhe bei mir selber durchführen und dem Streckenmodulautor einfach die geänderten Kacheln schicken. Das würde künftig nicht mehr gehen, weil ich ja nur die optimierten Kacheln zurückschicken kann. Zunächst mal sehe ich die Gefahr, dass der Autor irgendwann versehentlich seine unoptimierte Modulversion damit überschreibt. Aber selbst wenn das nicht passiert müsste er die Änderungen an der optimierten Version irgendwie in seiner unoptimierten Version nachturnen. Dazu wird er wahrscheinlich Erklärungen brauchen, was er tun muss. Das bedeutet, das ZPA hat Zusatzaufwand für Schriftverkehr. Und wenn ich als ZPA eines nicht haben will, dann ist das noch mehr Schriftverkehr. Denn das ist genau die Stelle, wo verdammt viel Zeit verloren geht.

Es wäre also die Frage, ob die Aussicht auf 6 fps mehr diesen Ambach wirklich wert ist. Letztens ist mein 1 Jahr altes Notebook kaputtgegangen. Als Ersatz bekam ich ein Gerät der jetzt aktuellen Hardware-Generation. Seitdem laufen alle Zusi-Strecken bei mir 4 fps schneller als auf dem Altgerät. Die per Subset-Zusammenführung reinholbaren 6 fps entsprechen also dem Fortschritt der Rechnertechnik in nur 1,5 Jahren. Etwa Mitte des Jahres 2020 hätten wir die selben 6 fps demnach allein dadurch reingeholt, dass die Computer schneller werden.

Meine Meinung ist eindeutig: Nicht zulassen.

Ich bin klar gegen zusammengeführte Meshsubsets oder allgemein gesagt: Es sollte nichts eingereicht werden dürfen, was der Pflege oder späteren Erweiterung Steine in den Weg legt. Im Falle des Abtauchens (Festplatten-Crash, kein Bock auf die Community mehr, Familie, ...) kann das Addon dann nicht mehr sinnvoll gepflegt werden.

Aus eigener Erfahrung:
Ich arbeite gerade an einem Projekt mit auch so einem Fall in Himmighausen, wo es der Ursprungsersteller mit der Community gut gemeint hat, aber die Umsetzung nicht State-of-die-Zusi-Art ist. In der Praxis hat er mir da eine fast unlösbare Aufgabe hinterlassen.

Just my 2ct.

Michael

Moin,

ich kann mich nur wiederholen. Ich hätte gerne eine Funktion, in der man mehrere Subsets markieren und dann, wenn die Parameter stimmen, zu einem Subset zusammenfassen kann. Es kommt bei mir sehr oft vor, dass ich für Anpassungen z.B. ein Teil eines Bahndamms lösche (Dreiecke löschen), um dann dort ggf. neu generieren zu lassen. schon habe ich Stückwerk, was nicht unbedingt notwendig ist. Auch bei der Bearbeitung von Gleisbettungen kann das vorkommen. Und hier wäre dann später bestimmt noch Optimierungsmöglichkeit, die ich aber gerne beeinflussen möchte.

Gruß
Hans-Peter

Hans-Peter Schramm hat geschrieben:Ich hätte gerne eine Funktion, in der man mehrere Subsets markieren und dann, wenn die Parameter stimmen, zu einem Subset zusammenfassen kann.

Dem kann ich voll zu stimmen. Bei meinen ersten Bautätigkeiten im Modul Ankensen hatte ich mir die Funktion genau so vorgestellt und dann zu spät gemerkt, was nach der Ausführung des Befehls passiert ist. Das ist mir später immer wieder vor die Füße gefallen und hat mir eine Menge Mehrarbeit eingebracht.

Ich würde vor schlagen, die vorhandene Funktion, wie Hans-Peter beschrieben hat, um zu gestalten.

Gruß
Jürgen

Bisher hätte ich auch gedacht, dass diese Funktion genau das macht, aber scheinbar legt sie alle gleichen Subsets zusammen. Etwas verwirrend, vielleicht sollte man sie entsprechend umbenennen? "Modulweit zusammenführen" oder so.

Hans-Peter Schramm hat geschrieben:ich kann mich nur wiederholen. Ich hätte gerne eine Funktion, in der man mehrere Subsets markieren und dann, wenn die Parameter stimmen, zu einem Subset zusammenfassen kann.

Ich habe auf Anhieb keinen entsprechenden Wunsch im Wünsche-Forum gefunden, hättet ihr mal schnell einen Link?