Eggu

Ja, das ist einsichtig. Danke für die Erklärung. Gruß Eggu

Gibt es Objekte, die man in den 2d-Ansichten nicht sieht (auch nicht aus der Nähe), weil diese offenbar gar nicht dargestellt werden? Anbei ein Beispiel mit Bäumen. Gruß Eggu

Bin zwar nur Eisenbahner-Laie, meine aber auch hier mehrfach gelesen zu haben, dass "Abfahrt aus Bahnhof" und "Streckenabschnitt frei bzw. besetzt" unabhängig voneinander sind. D.h. der Zug wird abfahrbereit gemacht, fährt dann los, fordert die nächste Fahrstraße an, und muss dann eben ev. wieder anhalten, wenn die F.S. nicht frei ist. Gruß Eggu

... dies ist nicht immer möglich, die Ursache konnte noch nicht eruiert werden. Genauere Beschreibung mit kleiner Diskussion erfolgte hier im Forum: shift-taste-verhindert-nicht-immer-das-einrasten Gruß Eggu

Ui, die Anlage "erschlägt" einen ja. Zunächst: Mir ist das Konzept deiner Fahrstraßenverwendung nicht klar: 1: Die Fahrstraßen sind viel zu lang, eine Fahrstraße soll doch nur einen kritischen Abschnitt absichern. 2: Warum werden in einer Wiederholung gleich mehrere Fahrstraßen angefordert ? Immer eine nach der anderen. Ist denn dann sichergestellt, dass der anfordernde Zug auch alle Fahrstraßen befährt und wieder freigibt ? Da scheinen mir Dead-Locks vorprogrammiert zu sein. Gruß Eggu

Ja, je weiter weg vom Startpunkt, um so weniger das Zittern. Auch wenn ich ein weiteres Segment kurz vor dem anderen platziere, snapt das Teil nicht an das Folgeteil, sondern zittert weiterhin. Wenn ich den Quadrat-Anfasser benutze, snapt es sofort an das Folgeteil. Aber das Teil ist dann wohl in einem anderen Modus, im Editor wird Winkel=0 angezeigt. Und wenn ich dann erneut einen Anfasser anklicke, springt das Spline-Teil sofort zurück in eine Gerade. Also, da ich diesen sehr störenden Effekt oft habe, bin ich nach wie vor an einer genaueren Analyse interessiert, und natürlich an Abhilfe. Gruß Eggu

Aha, danke für die Erklärung. Habe mal meinen Entwurf hochgeladen und die Beispiel-Bahnsteige gelblich texturiert. Das sind Abschnitte mit sanftem Bogen, entstanden durch Spline-Anpassung an die Gleise, so was kommt recht häufig vor bei mir. Sind das solch kritische Abschnitte ? 254C45FA-396D-4DC7-A9FC-4A97D4365660 Die darüber liegenden grauen Abschnitte sind ähnlich leicht gebogen, lassen sich aber smooth verschieben, ohne Zittern.

Einrasten ist aktiv, aber auch nach dem De-Aktivieren ist das Verhalten der Shift-Taste unverändert, also mit Shift: unkontrolliertes "Zitter"-Einrasten, ohne Shift: Einrasten auf minimaler Länge.

Nicht neu (für mich), aber jetzt muss ich doch 'mal nachfragen: Insbesondere wenn ich Gleise oder andere Splines an einem Ende ziehe (um z.B. den Spline zu verlängern, oder zu verkürzen), verhindert die Shift Taste nicht immer das Einrasten, oftmals springt das Ende wild hin und her, ich kann nicht erkennen , wo es einrasten will. Nimmt man statt den Achs-Anfassern den quadratischen Spline-Anfasser, so gelingt das Einrast-lose Verschieben, aber dann hat man eben keine genaue Kontrolle über die Richtung. Fotos anbei: Shift-move y-Handle Position 1 , Shift-move y-Handle Position 2 (keine Zwischen-Position möglich), und Verschiebung ohne Shift (also aktivem Snap): das eine Ende springt vollkommen zur anderen Seite (auf Minimal-Länge). Bekanntes "normales" (aber unschönes) Verhalten, oder brauche ich eine andere Tasten-Kombination ?

Du hast recht, eine Gruppe hat ihren eigenen lokalen Gizmo (mit Drehung 0 bei der Erzeugung der Gruppe). Problem tritt auf, wenn man 2 (oder mehrere) bereits gedrehte Objekte gruppiert (z.B. Mast mit Schild). Dann bekommt die Gruppe die Drehung 0. Also: Objekte bevorzugt gruppieren, wenn alle Objekte in "Grundstellung" sind. Das funktioniert aber nicht mehr, wenn ich bereits platzierte und gedrehte Objekte nachträglich gruppiere, oder wenn ich lediglich eine Mehrfachselektion verschieben möchte (wobei üblicherweise die Objekte nicht mehr in Grundstellung sind). Selbst wenn ich die Objekte in Grundstellung gruppiert habe, muss ich ev. die Gruppe später (dann ev. schon gedreht) temporär auflösen und wieder neu bilden (Workaround, um einzelne Objekte innerhalb der Gruppe nachträglich zu bearbeiten/transformieren). Gruß Eggu

Bisher ist der lokale Gizmo nur für Einzelobjekte möglich (so meine Beobachtung). Bei Gruppen oder Mehrfachselektionen bleibt der Welt-Gizmo wirksam, auch bei Anwahl des lokalen Gizmo. Bei Gruppen könnte der Mittelwert der einzelnen lokalen Gizmos als lokaler Gruppen-Gizmo gesetzt werden (so macht es Blender), oder alternativ kann man ein Referenzobjekt anwählen (hierdurch könnte man dann ein Objekt entlang einer beliebigen Achse verschieben, drehen). Gruß Eggu

Statt einer Modulvariable kann man eine Objektvariable als temporäre Variable nutzen. (Objekt = auslösendes Trigger-Objekt des Events). Damit umgeht man die Gefahr des Überschreibens. Diese Objektvariable wird bei erster Werte-Zuweislung automatisch angelegt. Man kann diese auch wieder am Ende des Events löschen. Gruß Eggu

Hallo Neo, das Depot-Ruckeln ist auch in V8.5 unverändert (schon ab einem Fzg. im Depot). Steht das auch noch auf der Agenda ? Gruß Eggu

Steht das noch auf der Agenda ? , also "komfortable" Bearbeitung von gruppierten Objekten, ohne eine Gruppe zuvor auflösen zu müssen ? (z.B. "Gruppe betreten/verlassen" und dann innerhalb der Gruppe arbeiten, als wäre diese aufgelöst"). War mal vage noch für die 8er Version angedacht. Gruß Uwe Eggert

Es gibt Tools (http://www.anywaysoft.com/text-to-voice/guide.html) , die nutzen die installierten Windows-Stimmen, "mittelgut".

Vermutlich hast du eine lokale Bild-Datei in der Anlage verwendet, zB als Textur. Diese müsste zunächst in den Katalog aufgenommen werden, also Freigabe durch Admin (Neo).

.. und warum in der Bedingung alle Fahrstraßen (ver-odert) "aufzählen", wenn doch sowieso ein Schlagwort ("Schranke schließen") vorhanden ist ? Gruß Eggu

Das ist das, was ich mit meinen "Formeln" weiter oben auch ausdrücken wollte. Gruß Eggu

Meine (unbestätigte) Vermutung war: Wenn sich die (neue) Kamera-Pos. immer nach folgendem Schema berechnen würde, dürfte es keine Verschiebung geben: Kamera-Pos-neu = Zug-Pos-neu + Verschiebungsvektor, wobei der Verschiebungsvektor einmalig beim Verknüpfen berechnet und beibehalten wird (Kamera-Pos - Zug-Pos) Aber Rundungsfehler könnten sich einschleichen bei: Kamera-Pos-neu = Kamera-Pos-alt + Delta, wobei: Delta = Zug-Pos-neu - Zug-Pos-alt Gruß Eggu

Vor einiger Zeit hatte ich das gleiche/ähnliche Thema angesprochen, dass manchmal nämlich "angeheftete" Objekte während der Fahrt sich nach und nach ein klein wenig verschieben und langsam wegwandern, z.B. Fahrgäste in einem Wagon. Es gab einige Erklärungsversuche, aber ganz schlüssig war es nicht (so meine Erinnerung), habe es dann aber weiter nicht mehr erforscht. Scheint ja aber weiterhin zu existieren, dieses Phänomen. Gruß Eggu

Super, habe ich schon länger nicht mehr gespielt. Ohne den Code in allen Details jetzt nachvollziehen zu wollen, so fällt doch gleich auf, dass bei den Events oben, unten und rechts ca. in der Mitte eine for- bzw. while-Schleife der Form vorkommt: for i, r in ipairs(t) do local liste = {} liste[1] = r[4] liste[2] = r[3] liste[3] = r[2] liste[4] = r[1] nur beim Event "links" fehlt diese Schleife, kann man das kurz begründen ? Gruß Eggu

jeder, der etwas längere/kompliziertere Arithmetik-Ausdrücke hat oder verschachtelte Objekt-Zugriffe, und Zwischenergebnisse mehrmals wieder verwenden möchte. (dachte, ich hätte das oben schon beschrieben). Man braucht das für die gleichen Zwecke wie unter Lua auch, man aber lieber die graph. EV nutzen möchte.

sicher, wäre aber aus meiner Sicht trotzdem ein Feature, dass man ohne großen Aufwand auch in der EV implementieren könnte.

Beim stark verschachtelten Zugriff auf Objekte kann man statt einem Einzeiler auch Mehrzeiler benutzen, und Zwischenergebnisse (insb. Teilpfade auf Unterobjekte) in local-Variablen zwischenspeichern. Das ist oft übersichtlicher, insbesondere, wenn man Teilpfade an mehreren Folgestellen wieder braucht. Oder auch bei längeren Arithmetik-Ausdrücken hilfreich, auch beim Debuggen von Zwischenergebnissen. In der graphischen EV muss ich, um gleiches zu erreichen, den Umweg über Objekt- oder Modulvariablen machen, obwohl diese Variablen ja nur temporär gebraucht werden. Könnte man local-Variablen nicht auch in der graph. EV anbieten ? Gruß Eggu

Hallo Bahnkater, ist das der aufgestaute "Frust" von 9 Jahren, die du jetzt schon dabei bist, oder speziell Neuerungen in V8 ? Kannst du 'mal die 3 Top-Themen nennen, die besonders "unlogisch" sind ? Gruß Eggu