Jump to content

Empfohlene Beiträge

Geschrieben
vor 35 Minuten schrieb wopitir:

für die Berechnung der Bremsverzögerung muss ich die gemessene Zuglänge in einer Objektvariablen hinterlegen.

Nur aus Neugier: Warum benötigst du die Zuglänge bei der Berechnung der Verzögerung?

(unabhängig davon ist eine Zuglänge natürlich ein nützlicher Parameter)

Geschrieben

:)Ein schelm wuerde  vermuten wegen dem abzubremsenden gewicht:P

Abba ich vermute eher damit die unterschiedlich langen zuege alle bei einer bestimmten stelle (vielleicht mittig eines bahnsteiges?) , nach entsprechender verzoegerung, zum stehen kommen. Ich nehme an das der eigendliche gleiskontakt dabei nicht so sehr im vordergrund der handlung steht wie die unterschiedlich langen verzoegerungsstrecken bei unterschiedlich langen zuegen. @Goetz, du hattest doch genau dazu ein nettes video gemacht

Cheers

Tom

Geschrieben
vor 32 Minuten schrieb metallix:

du hattest doch genau dazu ein nettes video gemacht

Genau.

Und aus diesem Video geht hervor, dass nur der Bremsweg eine Rolle bei der Berechnung der Verzögerung spielt. Dieser Bremsweg ist immer gleich, egal ob ich die Zugspitze, die Zugmitte oder den Zugschluss exakt positionieren will. Ich muss einfach entsprechend den Kontakt mit der Zugspitze, der Zugmitte oder dem Zugschluss auslösen.

Die Länge des Zuges spielt keine Rolle, es sei denn dass Wopitir etwas Besonderes vorhat. Drum meine neugierige Frage, inwiefern bei seinem Vorhaben die Zuglänge eine Rolle spielt.

Geschrieben

Hallo @Goetz,

es ist so wie Tom es schildert. Ich verwende einen Impuls beim Betreten eines Stop-Gleises für Fahrzeuggeschwindigkeit =0. Bis zum Signal habe ich eine feste Strecke bis zum Stillstand. Über die berechnete NegACC lasse ich den Zug dort hin rollen. Im Bahnhofsbereich habe ich einen Bahnsteig bei dem der Zug mittig anhalten soll. Hierzu benötige ich die Zuglänge die mit halben Wert in die Formel eingeht.
Egal wie schnell der Zug am Bremspunkt ankommt, entsprechend der berechneten Bremsverögerung bleibt der Zug richtig stehen.

Gruß
Wolfgang

Geschrieben (bearbeitet)
vor 48 Minuten schrieb wopitir:

Egal wie schnell der Zug am Bremspunkt ankommt, entsprechend der berechneten Bremsverögerung bleibt der Zug richtig stehen.

Das erreiche ich mit meiner Methode auch, @wopitir.

922930002_Bremsweg01.thumb.JPG.11d4bb77c4ebac48d1bee1e097519742.JPG

Am Bremspunkt berechne ich die Verzögerung mit vehicle.currentSpeed * vehicle.currentSpeed / Bremsweg.

Der Bremsweg im obigen Bild ist auf meiner Anlage mit 600 angegeben. Das ergibt beim H0 Maßstab die dargestellte Entfernung. Aus jeder Geschwindigkeit bleibt der Zug an dieser Stelle stehen. Wenn ich statt der Zugspitze die Zugmitte so positionieren wollte, dann müsste ich nur im Kontakt von "Betreten" auf "Betreten(Fahrzeugmitte)" umstellen. Mehr nicht. Und genauso könnte ich auch jeden Zugschluss dort stoppen, wo ich will: Mit der Kontakt-Einstellung "Verlassen"

Das macht die Geschichte einfach und überschaubar.

Will man auf eine andere Geschwindigkeit als 0 herunterbremsen und diese Geschwindigkeit am Ende des vorgegebenen Bremswegs erzielen, dann muss man ein currentSpeed durch die Differenz currentSpeed - Wunschgeschwindigkeit ersetzen. Also Differenz * currentSpeed / Bremsweg. Mit dieser Formel kann ich den Zug wahlweise stoppen (Wunschgeschwindigkeit 0) oder verlangsamen (Wunschgeschwindigkeit 40) und erreiche die gewünschte Geschwindigkeit nach der angegebenen Entfernung, egal, wie flott der Zug über den Kontakt rast. Für die Optik habe ich einen zweiten Bremspunkt viel weiter vorne, der den Zug auf einer Länge von 2800 auf 80 abbremst, wenn das folgende Signal Halt zeigt. Aber der Kontakt kurz vor dem Signal fängt mit der obigen Formel auch Raser zielsicher ein.

Bearbeitet von Goetz
ergänzende Erklärungen.
Geschrieben

Hallo @Goetz,

Deine Formel entspricht in etwa der meinigen. Da meine Anlage noch mit V4 erstellt wurde, musste ich das Ereignis "Zug betritt ein Gleis" verwenden, da es noch keinen Gleiskontakt gab. Ab V5 wird vieles einfacher. Daher vergesse die EV-4 und setze meine Anlage mit V5 und neuen Erkenntnissen neu auf auch wenn die bisherige unter V5 tadellos läuft. Muss aber noch viel lernen.
Gruß
Wolfgang

Geschrieben

Hallo,

zu dem Thema "Berechnung der Bremsbeschleunigung" gibt es diesen Thread:
Anlagen und 3D-Modelle>Anlagen>Virtuelle Spielwiese>Blocksteuerung mit Zweirichtungsbetrieb.

Gruß Wolfgang

Geschrieben (bearbeitet)

Hallo,
da ich da immer noch einem äußerst üblen Bug nachjage, muß ich mir einige Beispiele zurechtmachen. Kann ich, falls interessant, hier dann auch posten.
Mit den hier angehängten Beispielen mache ich zum Einen einen Kompatibilitätstest eines nicht ganz einfachen Konstrukts, und dann schauen wir mal, wie V5 intern tatsächlich arbeitet! Wen das interessiert, Konzentration einschalten, ansonsten beim nächsten Poster weiterlesen.

Also:
Um was geht's: Ich habe hier einen Kippschalter mit zwei Schalterchen. Lege ich den Kippschalter um, triggert er das erste Schalterchen. Das zweite ist eigentlich nur da um Nebenwirkungen zu checken.
Die beiden Ordner haben je zwei Ereignisse und die Ordner sind identisch, nur die Titel sind unterschiedlich. Auch hier ist der zweite Ordner nur da, um die Situtation noch etwas zu verkomplizieren.
Beide Ereignisse arbeiten mit dem _Trigger1-Trick, sollen also universell einen schaltenden Schalter verarbeiten. Die Schalterchen haben eine Objektvariable mit dem Namen Wert, der am Anfang auf nix steht. Außerdem gibt es noch eine normale Variable namens count, die einfach nur hochzählt, wie oft da wirklich was gemacht wird.
1.Ereignis: der betätigte Schalter soll seine Objektvariable von nix auf A stellen, dann drückt er sich selbst nochmal
2.Ereignis: nun von A auf B und auch nochmal drücken, was dann keine Wirkung mehr haben sollte.

kompatestV4V5 kann man in V4 laden. Kippschalter schalten, das Schalterchen1 endet mit Wert B. Fein. Aber wenn man sich count mal ansieht, das steht auf 6. wtf würde der Ami sagen. Ich will da jetzt gar nicht drauf eingehen, warum. Das Endergebnis ist wichtig und das ist wie gewünscht.
kompatestV4V5 nun in V5 laden. Kippschalter schalten, das Schalterchen1 endet mit Wert B. Und count steht tatsächlich auch auf 6. Hölle, hölle, aber es ist kompatibel!

Jetzt schmeiße ich mal alle Kompatibilitätsdelays raus. So geschehen in kompatestV5, was sich natürlich nur in V5 laden läßt. Nun mal Ereignisprotokoll einschalten und Kippschalter schalten. Jetzt wird's interessant. Das Schalterchen1 endet mit Wert B, aber count endet nun, wie es ein 'normaler' ;) Programmierer erwarten würde, auf 2.
Es sind nur zwei agierende Aktionen nötig gewesen!

Noch viel interessanter ist nun aber, wie das Ergebnis zustande gekommen ist.
Wie zu erwarten, schaltet das erste Ereignis in Ordner1 das Schalterchen auf A, aber - wer nun linear 'normal' weiterdenkt, sieht sich getäuscht - es ist NICHT sofort das zweite Ereignis des ersten Ordners und es ist NICHT das zweite Ereignis des zweiten Ordners das nun von A auf B setzt. Sondern: man sehe sich den Flow in der Ereignisprotokollierung an. Hier wird nun in der Tat mit rekursiven Aufrufen gearbeitet! d.h.: das von Ereignis 1 ausgelöste Selbstschalten des Schalterchens löst einen kompletten neuen Aufruf der EV aus! Es werden nun sofort erneut alle Ereignisse ausgeführt, die sich auf das Schalten eines Schalters beziehen! Wonach dann Ereignis 2 des ersten Ordners auf B setzt (aber halt erst, nachdem nochmal - natürlich jetzt ohne Auswirkung - über das erste Ereignis gelaufen wurde!). Bis der zweite Ordner mal drankommt, ist der Käse schon gegessen. Schalterchen steht schon auf B und es muß da nichts mehr gemacht werden.
Also: die Funktionsweise muß nun verinnerlicht werden, denn sie bedeutet, dass da mitten in der Aktionsliste eines Ereignisses ganz schön viel mit einer Anweisung passieren kann. Irgendwie sehe ich da allerdings auch die Gefahr einer Endlosschleife mit immer tiefer laufendem Stack - also Crash...

Gruß
  Andy

ps.: Selbstverständlich ist mit diesen rekuriven Effekten diese Programmierung des Problems alles andere als ideal, denn insgesamt kümmert er sich um 17 Ereignisse. Die Lua-Version ist da optimaler...

kompatestV4V5.mbp

kompatestV5.mbp

kompatestV5Lua.mbp

Bearbeitet von Andy
ps
Geschrieben (bearbeitet)

Hi @Neo,

I have just had my first look at v5 beta and without having had time yet to dive into the new programming interface, I love especially the shadows addition :)

This is of course a beta and I have a little initial feedback for you:

1) Suggestion, Vegetation category name.
You have made 3 tree subcategories: "Deciduous trees", "Conifers" and "Other trees"
I would suggest to emphasize "trees" in all categories:  "Deciduous trees", "Conifer trees" and "Other trees"
This makes it easier for the user to identify "Conifers" as a major tree subcategory.

2) Wrong online catalog placement, 3 of my own trees are in the wrong subcategory
The following 3 trees are right now in the "Conifers" subcategory. They are leaf trees and should be moved to the "Deciduous trees" subcategory.
Leaf Park4
EBDA5DF4-C48C-454A-8152-0EC79CC169DF
Leaf Park1
8623FCA2-7FEE-46CF-B0B6-8511FB43B840
Leaf Park3
F6B038D3-3E7B-462C-9C94-9C5013CD498C

The next 2 are suggestions, that should have been made in an Alpha version, since you have now finalized functionality in the betas.
But I will still request them due to their usefulness. 

3) Feature request, Switch of shade on specific object.
With the addition of shadows, some objects should not always cast shadows. Specifically backgrounds and particles.
On one of my layouts, the background now cast long shades on the entire layout, effectively leaving the layout "in the dark".
If we could switch of shading manually on an objects property panel, problem would be solved. Also for other types of objects.

4) Feature request, allow the replacement function to replace variations.
If I have used a variation of a tree, perhaps a winter variation, I can not replace this with another variation of another tree.
Allowing replacement on variations level would create extra flexibility when updating a layout to newer and better assets.

Kind regards,
Henrik :)

 


 

 

Bearbeitet von henricjen
Geschrieben (bearbeitet)

Hallo Neo,
nochmal kurz zurück auf den oben beschriebenen Flow. Mir wär's wirklich lieber gewesen, wenn eine Aktion ein Flag gesetzt hätte, dass noch mal ein Durchlauf nötig ist und erst am Ende des Gesamtcodes alles nochmal durchlaufen wird, solange Flags gesetzt sind. Das rekursive Verhalten ist verdammt schwer nachvollziehbar und außerdem gefährlich.

Gruß
  Andy

p.s.: Anhang bringt den Stack ganz einfach zum Überlaufen. Übrigens warnt er auch nicht, wenn ich Schalterchen2 weglösche, dass dies noch in Ereignissen drinhängt (wie es in V4 der Fall war). Und den Namen behält er auch noch bei (Kippschalter Aktionen - hier jetzt rausgelöscht).

 

kompatestV5overflow.mbp

Bearbeitet von Andy
p.s.
Geschrieben

Hallo,

vor 18 Stunden schrieb randermann.tbb:

Ich habe aus dm Katalog V4 unter der Rubrik Module das Modul 2-19 Verladung geladen und es erscheinen Fragezeichen.

das hat mit dem neuen V5-Katalog nichts zu tun, sondern mit einem Fehler in V4. Es gab dort noch Probleme bei Gruppen im Online-Katalog, wenn sich Unterobjekte nachträglich geändert haben. Das Fragezeichen verschwindet allerdings, wenn du die Anlage speicherst und neu lädst. In V5 gibt es dieses Problem nicht mehr.

vor 18 Stunden schrieb Henry:

welches direkt zum Ausgangsmodell in der nun geöffneten Baumstruktur führt.

Gute Idee, ich glaube ich kann hier noch den ein oder anderen Shortcut einbauen.

vor 18 Stunden schrieb Henry:

Nebenbei möchte ich bemerken, daß es Längenunterschiede (42, 45 mm) zwischen den oben abgebildeten Modellen gibt. Warum ?

Um welche Modelle konkret handelt es sich? Hast du dich diesbezüglich schon an die Modellbauer gewandt?

vor 16 Stunden schrieb metallix:

und dadurch die scroll function der maus einen comfortableren zugriff auf gewuenschte ebenen ermoeglichen wuerde.

Danke für den Hinweis, das ist natürlich nicht gewollt, dass das Mousewheel dort nicht funktioniert. Wird korrigiert.

vor 6 Stunden schrieb wopitir:

Wäre es möglich die Gesamtlänge eines Zugverbandes als Eigenschaft eines Triebfahrzeuges (oder was auch immer) zu übergeben

Ich habe mir das als Feature-Wunsch notiert.

vor 3 Stunden schrieb henricjen:

1) Suggestion, Vegetation category name.

2) Wrong online catalog placement

Thank you for your suggestion, I've changed the category name and moved the wrong trees to the right category.

vor 3 Stunden schrieb henricjen:

3) Feature request, Switch of shade on specific object.

Yes, there will be improvements to the shadows for special situations.

vor 3 Stunden schrieb henricjen:

If I have used a variation of a tree, perhaps a winter variation, I can not replace this with another variation of another tree.

You can still replace the old tree with another tree and switch then to another variation.

vor 2 Stunden schrieb Andy:

Das rekursive Verhalten ist verdammt schwer nachvollziehbar und außerdem gefährlich.

Das rekursive Verhalten entspricht, wie du selbst schon festgestellt hast, dem normalen Ablauf eines Programms. Diese verzögerte Ausführung von Ereignissen vor V5 basierte auf einer "Abkürzung", die ich vor über 12 Jahren im alten 3D-Eisenbahnplaner getroffen habe. Damals empfand ich das Sammeln von Aktionen als einfachste Lösung, um Stack-Overflows zu vermeiden. Heute weiß ich es besser, und muss keine Klimmzüge mehr machen, um Endlosschleifen bei der EV zu verhindern. Einen Stack-Overflow gibt es nicht, das Studio bricht die Abarbeitung bei 25 Rekursionsebenen ab. Hier sollte der Planer dann schnell erkennen, dass er etwas falsch gemacht hat.

Gefährlich ist das Verhalten nicht, man muss sich dem natürlich bewusst sein. Das musste man aber auch in allen anderen Versionen bisher, denn diese verzögerte Ausführung war nicht intuitiv und viele Leute mussten darauf erst hingewiesen werden. Jetzt ist alles einheitlich: Wird etwas geändert, führt die Änderung zu einem Ereignis, was abgearbeitet wird. Nichts anderes ist Lua, wo Funktionen andere Funktionen aufrufen.

vor 2 Stunden schrieb Andy:

Übrigens warnt er auch nicht, wenn ich Schalterchen2 weglösche, dass dies noch in Ereignissen drinhängt (wie es in V4 der Fall war).

Die Warnungen gibt es auch weiterhin, aber nur für Objekte, die direkt in der EV referenziert werden. Wenn du ein Ereignis "Beliebiger Schalter wird betätigt" hast, und einen beliebigen Schalter löschst, erscheint keine Warnung. Die Warnung hat ja den Zweck, dich auf Ereignisse hinzuweisen, die anschließend nie mehr ausgeführt werden, weil das entsprechende Objekt fehlt. "Globale Ereignisse" funktionieren ja weiter, wenn du einen von vielen Schaltern löschst.

Viele Grüße,

Neo

Geschrieben (bearbeitet)
vor einer Stunde schrieb Neo:

Die Warnungen gibt es auch weiterhin, aber nur für Objekte, die direkt in der EV referenziert werden.

Naja, es wird eine Objektvariable davon direkt beeinflusst. Und die dritte grüne Zeile bleibt auch genau so erhalten, wenn Schalterchen2 weg ist.

 

ausschnitt.jpg

Bearbeitet von Andy
ergänzung
Geschrieben

Hello,

I try to read the different interventions, but it is very difficult as they are written in german and translation takes time.  So, sorry if my questions were already posted and replied :

  1. In V4, there was a button to export the events in order, for example, to print them.  I don't find this option in V5
  2. In V4, one can use Trigger1 & 2, depending on the action or condition expressed; now, in V5, these were removed and replaced by Trigger but I have some difficulties to see how to use it now.  For example, in the demo furnished with V5, I discover that "vehicule located on track" has the following parameters :
    - Vehicule : Any
    - Trigger : one have the choice between "Vehicule", new track or last track  -  What is the meaning of these parameters ?

    - Name : name of the variable
  3. What is the differnece between "Variable" and "Variable (Extended)"?
  4. Is it possible to have a list of all variables and how?
  5. In general, is it possible to have a detailled description of the different parameters and the good way to use them?

Thank you for your comprehension

Rgards

André

Geschrieben

Hallo zusammen,@NEO wäre es möglich das Umschalten zwischen Tag/Nacht mit einem Icon an der oberen Leiste zu ermöglichen zum Schnell-Testen ohne daß man in den Dialog dazu gehen muß, würde für mich zum Testen von Modellen das Ganze sehr erleichtern.

lg max

Geschrieben
vor 4 Stunden schrieb Andy:

Naja, es wird eine Objektvariable davon direkt beeinflusst. Und die dritte grüne Zeile bleibt auch genau so erhalten, wenn Schalterchen2 weg ist.

 

ausschnitt.jpg

image.jpeg.50a7b4bf1d3dde28257cee85ee2ab013.jpeg

Diese Art ging noch nie als integriertes Objekt durch ;)

Gruß Frank

Geschrieben
Am 14.7.2019 um 21:31 schrieb Neo:

Schaut euch mal die Demo-Anlage unter BF5271F1-E762-40A5-9886-AA42441B9E38 an. Dort gibt es Aktionen, die von zwei Schaltern ausgeführt werden, jedoch mit unterschiedlichen Parametern. Ein Schalter startet die Lok sofort, der andere um 2 Sekunden verzögert. Dahinter stecken die gleichen Aktionen, nämlich in einem benutzerdefinierten Ereignis zusammengefasst, mit individuell konfigurierten Parametern. Die zwei Schalter rufen dann einfach nur dieses benutzerdefinierte Ereignis mit eigenen Parametern auf.

Benutzerdefinierte Ereignisse sind quasi die Nicht-Lua-Variante von "globalen Funktionen", können also zum Zusammenfassen von gemeinsam genutzten Aktionen/Bedingungen genutzt werden. In meinem Beispiel hätte man die Redundanz natürlich auch mit Objektvariablen der Schalter lösen können, aber sobald verschiedene Ereignisse (z.B. Weiche schaltet ODER Schalter wird betätigt) die gleichen Aktionen aufrufen, sind benutzerdefinierte Ereignisse eine Lösung.

Ist genial (y)(y)(y), aber es gibt zwei Sachen die mir Aufgefallen sind:

Wenn ich Parameter anlegen will sind Buchstaben wie „Ä“ „Ö“ und „Ü“ nicht zugelassen, hat dies was mit LUA im Hintergrund zu tun?

image.jpeg.3c45e77e5716ed8e97153223c310d727.jpeg

Und wäre es Möglich auch bei VariablenNAMEN einen Auslöser mit einzubauen, Entweder dass man sich die entsprechende heraussuchen kann oder dass vielleicht zumindest ein Text eingetragen werden könnte?

Gruß Frank

Geschrieben
vor einer Stunde schrieb Easydiver:

Im V4 ging es so....

2

Hi Maik

Ich glaube in V5 geht es derzeit nur so:

notebook-2757626_960_720.thumb.jpg.90f1f8fec120c24a91ca96b8d5c2fc85.jpg

Soweit ich weiss existiert auch noch keine weiterverbartungs weichware wie z.b @BahnLand's XML auswerter.....

Cheers

Tom

Geschrieben

Hier noch einige verbesserungsmoeglichkeiten in sachen comfort:

Sowohl timer als auch variablen koennen in V5 ausschliesslich ueber die ereigniss section oben links in der EV initiert werden. Dabei werden bei timern 10 sec voreingesellt und ein haekchen ist beim automatischen neustart gesetzt.

btest1.thumb.JPG.9ebfbafdda84ccfecfc827c7bb6b68c8.JPG

Wenn der timer in einem ereigniss gestartet werden soll erscheint zunaechst das entsprechend voreingestellte menue-fenster

btest2.thumb.JPG.8b7f36f536740c2334557c059ff995ee.JPG

Es aendert sich nicht wenn der entsprechende timer ausgewaehlt wird, auch eventuelle aenderungen der dauer und restzeit werden nicht uebernommen, ebensowenig wie die deaktivierung des automatischen neustarts.

btest3.thumb.JPG.a0860e15c41e9e5e732916598a7528a1.JPG

In V4 konnten timer "on the go" waehrend eines eintrages initiert werden und waren anschliessend auch sofort ueber die timerliste auswaehlbar. Um den comfort in V5 zu erhoehen schlage ich vor diese moeglichkeit  wieder einzubauen. Dabei sollten die an einem ende (also entweder in der timerliste oder direkt in einer aktion) gemachten eintraege/aenderungen auch genau so in der anderen wieder gegeben werden. Also wenn ein timer in der timerliste initiert wird sollte er genau so wie er eingestellt wurde anschliessend, nach erfolgter auswahl, im aktionsfenster abgebildet sein. Umgekehrt sollte er genau wie er im aktionsfenster eingestellt wurde auch in der timerliste abgebildet werden. Der automatische neustart sollte nicht voreingestellt aktiv sein. Derzeit muss er tasaechlich sowohl im aktionsfenster als auch in der timerliste deaktiviert werden, wenn er nicht gewollt ist. Vielleicht gaebe es ja eine moeglichkeit fuer user, eine gewaehlte voreinstellung in den programm einstellungen zu definieren.

 

Aehnlich sieht es mit variablen aus. Variablen koennen nur in der variablenliste erzeugt werden, sonst koennen sie nicht in einem aktionsfenster ausgewaehlt werden. Schlimmer noch: eine eingetragene variable die z b im testlauf geleert/geloescht wurde, ist nicht mehr in der variablenliste gefuehrt und kann auch nicht mehr im auswahlfenster einer aktion gefunden werden bis sie durch eine aktion, in der sie bereits eingetragen war, wieder gesetzt wird oder neu in die variablenliste eingetragen wird. Auch hier werden einstellungen nicht uebertragen, siehe beispiel neuer eintrag in variablenliste als text-typ.

btest4.thumb.JPG.184d1ebfdde7d55d4d714c562d377df5.JPG

Das zunaechst leere aktionsfenster mit voreingestelltem zahl typ

btest5.thumb.JPG.e617157b79c289b6ec15303f12a3a560.JPG

Das aktionsfenster mit der neuen variablen ausgewaehlt

btest6.thumb.JPG.1ed1cd7ebf92871bf5535e1f36596355.JPG

Auch hier bei den variablen schlage ich vor das das eintragen einer variablen an beiden enden moeglich ist und die eintraege genau an beiden enden auch so wiedergegeben werden. Zudem sollte die variablenliste immer alle in der EV enthaltenen variablen anzeigen, also auch solche die zeitwese leer/geloescht sind.

btest7.thumb.JPG.bcc837be5fa03b019676067d2d19f194.JPG

Hier ist es deutlich zu  sehen, es existiert ein eintrag mit einer bestimmten variablen, abba sie kann nicht in einer neuen aktion aus der liste ausgewaehlt werden.

Bei den gleiskontakten,die eine suuuper erleichterung darstellen durch ihre flexibilitaet in der einfachen positionierung und ihre definierbare wirkungsrichtung finde ich die festgelegte voreinstellung auf betreten etwas uncomfortabel.

btest8.JPG.c03a9b26cb63218833bb3360af126ffa.JPG

Hier waere entweder ein button, der das optionale festhalten einer einmal gewaehlten option bewirkt, oder das verbleiben einer option in einer geaenderten wahl  bis zu einer naechsten aenderung eine grosse erleichterung.

btest9.jpg.d1ea0a1b5a8c8b3e3081a2925ada34bd.jpg

Cheers

Tom

Geschrieben

Viele meiner Probleme werden sich lösen lassen, wenn ich z.B. mal allen relevanten Objektgruppen ein Schlagwort zuordne.
Das wäre auch schön, wenn das im Zuge einer Mehrfachauswahl möglich wäre. Gibt's einen Lua-Befehl, über den man ein Schlagwort zuordnen kann?
Dann könnte ich mir von V4 den XML-Auswerter schnappen, die Objektvariablenliste nehmen, ein wenig Textprocessing machen, einen Table generieren, als Lua-Code einfügen und dann einmalig ein Knöpfchen drücken, das mit dieser Sysiphos-Arbeit abnimmt.

Ansonsten gilt für den Export. Das geht nur mit V5 komplett. Ab in die Apollo-Jubiläums-Rakete und .. :P

Gruß
  Andy

Geschrieben

Hallo,

vor 20 Stunden schrieb Andy:

Naja, es wird eine Objektvariable davon direkt beeinflusst.

nicht direkt, wie schon Frank erkannt hast, spricht du die Objektvariable nur indirekt an, über einen Objektnamen. Da sich hinter einem Namen viele Objekte verbergen können, kann das Studio bei solchen indirekten Zugriffen nicht warnen (wie auch schon in V4).

vor 19 Stunden schrieb ademes:

In V4, there was a button to export the events in order, for example, to print them.  I don't find this option in V5

Not yet, but this feature will be included in the final release.

vor 19 Stunden schrieb ademes:

one have the choice between "Vehicule", new track or last track  -  What is the meaning of these parameters ?

Vehicle points to the train, which entered the new track. "New track" points to the entered track and "Last track" points to the leaved track.

vor 19 Stunden schrieb ademes:

What is the differnece between "Variable" and "Variable (Extended)"?

The first is used when addressing a single, specific variable. Extended is used when addressing a variable, where the object or the variable name itself can be a variable itself. The logic behind both is the same, it is just a simpler user interface.

vor 19 Stunden schrieb ademes:

Is it possible to have a list of all variables and how? 

All variables of what? Variables of an event module are listed in the event management, variables of an object in the variable editor (right click on an object and select "Keywords/Variables".

vor 19 Stunden schrieb ademes:

In general, is it possible to have a detailled description of the different parameters and the good way to use them?

A detailled documentation will be available when the final version is released in september.

vor 14 Stunden schrieb fzonk:

Wenn ich Parameter anlegen will sind Buchstaben wie „Ä“ „Ö“ und „Ü“ nicht zugelassen, hat dies was mit LUA im Hintergrund zu tun?

Genau, Parameternamen sind nichts anderes als Lua-Variablen. Dass du normale Variablen mit Umlauten schreiben kannst, liegt daran, dass sie nur Tabelleneinträge sind, und hier gibt es keine Beschränkungen.

vor 14 Stunden schrieb fzonk:

Und wäre es Möglich auch bei VariablenNAMEN einen Auslöser mit einzubauen,

Was meinst du damit, ein Ereignis, was ausgelöst wird, wenn sich der Name einer Variable ändert? Was bezweckst du damit?

vor 3 Stunden schrieb Easydiver:

Wie kann ich im V5  die EV exportieren ?

Das funktioniert aktuell noch nicht, das wird mit der finalen Version zur Verfügung stehen. Warum will du die Ereignisse exportieren?

vor 47 Minuten schrieb metallix:

Sowohl timer als auch variablen koennen in V5 ausschliesslich ueber die ereigniss section oben links in der EV initiert werden.

Du kannst Timer und Variablen auch dynamisch erzeugen, wie in V4. Dafür musst du lediglich "Timer (Erweitert)" bzw. "Variable (Erweitert)" verwenden. Trage unter Name dann einfach einen beliebigen Namen ein.

vor 48 Minuten schrieb metallix:

Es aendert sich nicht wenn der entsprechende timer ausgewaehlt wird, auch eventuelle aenderungen der dauer und restzeit werden nicht uebernommen, ebensowenig wie die deaktivierung des automatischen neustarts.

Das kann ich gern noch verbessern.

vor 50 Minuten schrieb metallix:

Der automatische neustart sollte nicht voreingestellt aktiv sein.

Einmalig auslösende Timer sind nur noch aus Kompatibilitätsgründen vorhanden, d.h. Timer gelten in V5 standardmäßig als "Taktgeber", lösen also kontinuierlich aus.. Willst du nur einmalig eine Aktion verzögern, empfehle ich die weitaus möchtigere Aktion "Ausführung verzögern". Dabei bleiben nämlich die Auslöser erhalten und du musst solche Daten nicht irgendwo zwischenspeichern.

vor 53 Minuten schrieb metallix:

eine eingetragene variable die z b im testlauf geleert/geloescht wurde, ist nicht mehr in der variablenliste gefuehrt

Ich würde Variablen nicht mehr löschen, um sie auf einen Anfangswert zurückzusetzen. V5 kennt verschiedene Wertetypen (Zahlen, Strings, Boolean, Objekte...), und im Interesse einer übersichtlichen Struktur würde ich Variablen im Vorfeld definieren und gleich den Typ angeben, damit man sieht, was dort in Zukunft mal gespeichert wird.

vor 57 Minuten schrieb metallix:

finde ich die festgelegte voreinstellung auf betreten etwas uncomfortabel.

Ist das wirklich ein Problem? Die Einstellung ist doch ruckzuck geändert. Wie viele Ereignisse hast du denn, wo du so eine Umstellung vornehmen musst?

vor 10 Minuten schrieb Andy:

Gibt's einen Lua-Befehl, über den man ein Schlagwort zuordnen kann?

object.variables["Mein Schlagwort"] = keyword

 

vor 11 Minuten schrieb Andy:

Das geht nur mit V5 komplett. Ab in die Apollo-Jubiläums-Rakete und

Was möchtest du damit sagen? Wenn du unzufrieden mit V5 bist, kannst du gern V4, V3, V2, V1 oder den alten 3D-Eisenbahnplaner verwenden, du hast die freie Wahl.

Viele Grüße,

Neo

Erstelle ein Benutzerkonto oder melde dich an, um zu kommentieren

Du musst ein Benutzerkonto besitzen, um einen Kommentar verfassen zu können

Benutzerkonto erstellen

Neues Benutzerkonto für unsere Community erstellen.

Neues Benutzerkonto erstellen

Anmelden

Du hast bereits ein Benutzerkonto? Melde dich hier an.

Jetzt anmelden
×
×
  • Neu erstellen...